Forums

by Craig Shearer >> Wed, 18 Jul 2001 1:01:24 GMT

Greetings all...

Does JADE need an integrity checking mechanism? Some relational databases have integrity checking built in, meaning that the database enforces integrity automatically.

JADE has some integrity checking features - such as automatic inverses, parent-child relationships etc. Also, if you force all access to an object through methods, then much integrity checking can be done here. But, there are still potential holes that may not be able to be checked using existing mechanisms.

As an example, it's usually desirable to implement validation of an object in a method on that object's class, rather than in methods (usually on form classes) that maintain the object. This ensures that validation is the same for all users of the class. While one could write a validation method, it's up to the developer to remember that it must be called.

What I'd like to have is a facility to writing a method that checked the integrity of an object immediately before changes to that object were committed to the database. So, if I update a bunch of objects in a transaction, each object would have its checkIntegrity method automatically called (if one was implemented) immediately before the commit. This method would then have the ability to abort the transaction and raise an exception if all was not well.

What do others think of this?

Craig Shearer
--
Chief Architect
Helix Software Limited
http://www.helix.co.nz
craig.shearer@helix.co.nz
Phone: 025 936 334

by Carl Ranson >> Wed, 18 Jul 2001 6:19:26 GMT

Your effectivly implementing a "Class Invariant" by doing this. (I first came across this concept in the Meyer's epic book "OO Software Construction Second Edition")

In my opinion its only part of an overall strategy for reliability, but seems worthwhile doing if reliability is important for the system in question. (Easy to do, too, if you encapuslated the database stuff in a transaction manager)

I note that you only plan to check the object before committing a transaction. The Eiffel method takes this further, by making the class invariant check part of every method call on that object. If a method doesn't uphold the class invariant then an exception is raised.

Cheers,
CR

by Krull >> Wed, 18 Jul 2001 13:09:45 GMT

Hi Craig,

Have you come across the class under the RootSchema Exception hierarchy called IntegrityViolation? Hmmmmm, I wonder what that could be for?

Does JADE need an integrity checking mechanism? Some relational databases have integrity checking built in, meaning that the database enforces integrity automatically.

I agree with the approach of defining and enforcing model 'integrity constraints' at the database level. This normally means that constraints are specified in a declaritive manner (rather than procedurally) and enforced by the system at runtime. If you include the logical quantifiers 'forall' and 'exists' any integrity constraint can be specified using a predicate, which is just a form of 'conditional expression'. I also believe it is desirable to enforce 'integrity contraints' as immediately as possible and not defer checking to until commit time (they could also work with transient object then). There are various ways to achieve this, one solution is to introduce the concept of a multiple assignment statement similar to that proposed by C J Date for the Relation Model in 'The Third Manifesto'. Another is to bracket multiple assignments in some way. If you defer integrity checking until commit time, then it is possible for an updating process to violate integrity within its own transaction and see an inconsistent state, which is undesirable.

With integrity constraints defined in the schema, when a constraint was violated this would raise an exception (Integrityviolation might be useful after all) that would ulimately abort the transaction.

Note: that this style of integrity checking is primarily intended to prevent applications, external users or tools from compromising the integrity of the object model as specified in the object model itself; It is not intended as a replacement for user input validation, which is a separate application issue.

by Wilfred Verkley >> Wed, 18 Jul 2001 21:45:01 GMT

"Multiple assignment" sounds like a "small transaction", but only in regards to object integrity. Im not sure if im keen on this idea. An object interface should be as easy to use as possible. Users shouldnt be concerned with order of setting proproperties, or which to surround with multiple assignment brackets. Wouldnt it introduce a much tighter coupling? It should be up to the designer of the object to implement the interface and behaviour in a way that encourages object integrity i think i.e. two closely related properties set in the same accessor with an exception raised if the values are invalid.

Some integrity rules are also quite complicated, and its data structures can be set and manipulated in many different ways. Wouldnt such complicated relationships be easier to check at commit time? i.e. checking to see if the "family tree" in a geneology database is valid. Also, would these integrity rules need to execute on the server, or in the local object cache?

Wilfred.

by Krull >> Thu, 19 Jul 2001 10:23:21 GMT

"Multiple assignment" sounds like a "small transaction", but only in regards to object integrity. Im not sure if im keen on this idea.
An object interface should be as easy to use as possible. Users shouldnt be concerned with order of setting proproperties, or which to surround with multiple assignment brackets. Wouldnt it introduce a much tighter coupling?

Yes, I tend to agree - the best solution to this should involve no additional complexity for users of an interface. There are cases today where the order of setting properties affects performance e.g. assigning inverse reference before key properties incurs additional key change overhead. Now, if the interface in question provided an 'update method'. If we could somehow specify that such a method was a special 'updater method' i.e. one that will transform the receivers state from initial or a consistent state to another consistent state, such a method could be the boundary for integrity checking and further the system could potentially optimise (or reorder) non-optimal property changes within such 'updater' methods. A consistent state would be defined as satisfying all integrity constraints or simply that the predicates all evaluate to true [pretty much the 'class invariant' that Carl mentioned]. Note: however, that more complex integrity constraints could involve multiple objects.

It should be up to the designer of the object to implement the interface and behaviour in a way that encourages object integrity i think i.e. two closely related properties set in the same accessor with an exception raised if the values are invalid.

With today's capabilities, one way to implement 'model integrity' is to encapsulate updating logic in one or sevaral 'update' methods that all guarantee to change an object from one consistent state to another consistent state. It is not possible to maintain this type of control [over integrity] if you publish individual setter methods in a class inteface, since given setter methods users of the interface can change the state of instances in arbitrary ways. Such an 'update' method would typically check input parameters and raise a [precondition] exception when a precondition was violated. The update method would be responsible for performing the state changes to the object - during method execution the receiver might at times be in an inconsistent state; however, at the end of the method it should again be consistent.

Some integrity rules are also quite complicated, and its data structures can be set and manipulated in many different ways. Wouldnt such complicated relationships be easier to check at commit time? i.e. checking to see if the "family tree" in a geneology database is valid.

Yes, it is often easier to do the check at commit time, that is why RDBMSs generally implement constraint checking that way (some provide an option between immediate and deffered). However, I still believe the more immediately you can do the checking the better for a number of reasons. An example of an integrity constraint that JADE enforces today, is 'no duplicates' on a sequence of key properties. This constraint is checked and enforced immediately on each operation (dictionary add - directly or via inverse assignement) - the result is direct feedback and the ability for the application to deal with the exception relatively easily. This would be much harder to deal with if the checking were to be deffered until commit time. A better example might be non-null constraints - in a transaction that updates or creates a large number of instances it would not be very convenient to deal with or diagnose exceptions that occured when one (or several) instances violated the non-null constraint when the application executed commit;

Also, would these integrity rules need to execute on the server, or in the local object cache?

I would say in either location - in the same way that inverses, key change propagation duplicate key constraints etc. are executed were they are triggered. This currently means that the application developer can control the execution location.