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.