[Seaside] Prevayler

[Avi Bryant]

On Tue, 19 Mar 2002, Cees de Groot wrote:

>
> avi@beta4.com said:
> > There seem to be two obvious
> > ways of handling this - either the stub becomeForwards itself into the
> > object, or the stub sticks around and just forwards all method sends
> > to the real object.
>
> A third, non-obvious, way is that you rewrite the class and adapt the browser
> to hide this from the user. A fourth way is that you simply compare versions
> of the object to determine whether anything has been changed. A fifth way
> would entail method wrappers (that's a very promising way - clean, available
> now, reasonably easy to work with).

Hang on - I think we're on different wavelengths here.  First, comparing
versions of the objects is fine, but you still need some kind of stub
unless you bring everything into memory.  Second, if you're using a stub
that goes away, how do you know which objects to compare versions of -
that is, how do you register the fact that a particular object has been
used in a particular transaction?  Surely you don't scan every object in
the system?

Rewrite hacks and method wrappers are ok, but they operate on entire
classes, not single objects.  This means that you have to have completely
separate classes for persistent objects and non-persistent objects,
including special persistent versions of the collection classes, etc.  Not
ideal.

> The manual method works fine with stubs that go away, indeed. If you
> want automatic detection of changes, pull your objects to a higher
> level class (see further below).

Hmm.  The metadata approach is definitely useful (it is quite
familiar to me in the sense that O/R mapping requires the same data),
but I'm not convinced that it should be required just to get automatic
change detection.  Supporting lightweight, idiomatic smalltalk development
with persistence is still, I think, a worthwhile goal.

You do have me thinking about what could be done with seriously
non-transparent methods like Objectiva, though.  I admit that there's no
real reason your business objects should have to look entirely like
"normal" smalltalk objects, although for portability reasons I'm uneasy
with going so far that you need tool support to make things manageable.

Avi