[T2-users] X [Dbix-class] Live object index support ported

[Jean-Louis Leroy]

> If you rely on cached objects, then this breaks that precondition made
> by database writers.  The information about which rows are accessed in a
> transaction are not available, and only updates to objects (or explicit
> refresh requests) will cause the version check.  This may or may not be
> a problem for a given application; in other words, the bug still exists,
> it is just a lot more subtle.

The rationale was that the state of the objects in the cache was
copied to several other UI objects. We wanted to keep the UIs
consistent with the objects in-memory. So we didn't want the state of
the cached objects to change silently and pull the rug from under the
UI's feet.

I remember that I made a difference between aggregated objects and
those which were merely pointed to. I didn't manage to convince my
team mates that this difference was important though, but I think it
addresses your remark about not all versions being checked.

Here it is: first consider our usual Simpson example: Person has a
(pointer to) a partner and a collection of (pointers to) children.

Let's assume that process #1 has the Simpson family in cache. I
modifies Homer (e.g. bumps his age) and attempts to save him. Note
that this doesn't touch Marge's row. Version control occurs; if
process #2 has performed an UPDATE on Homer the save fails. Otherwise
it succeeds - let's consider this scenario.

But what about the objects (directly) referenced by Homer? Suppose
that in the meantime process #2 has bumped Marge's weight and
successfully saved her.

The way I view things, changing Marge's weight doesn't change Homer, and
thus no version check should occur. Changing Homer means changing any
of his "terminal" fields (name, age, weight), divorcing or marrying
him, adding or removing a child. That's all. Oh yes, if Homer had
composition-style relationships, e.g. Person <>--2> Leg, changing any
of Homer's legs would be considered as a change to Homer as well.

I mention *direct* references above. But what would happen if we
decided that Marge's weight gain changes Homer? Then you'd be forced
to consider changes to Patty and Selma as well (if Person has a
collection of siblings); iow any update on an object would imply a
version check on all the objects in its transitive closure.

Now perhaps that's what we want, why not? But IMO Tangram has no
business doing locking or version control, because there are many
possible strategies. That's why the version control stuff is nowhere
to be found in Tangram itself - it was implemented in a derived,
app-specific storage.

BTW I was personally against using version checks in the Appeal Court
project. My opinion was that the object was not the right level of
locking (or version-checking). I (somewhat vaguely) argued that the
right level was the Use Case.


I have serious doubts about using the database as a locking
mechanism. The whole point of Tangram is to enable you to work in
terms of objects, not rows or tables.
-- 
Jean-Louis Leroy
Sound Object Logic
http://www.soundobjectlogic.com