Re: release 3.4 (Was: [Waterken-server] org.yurl.Author schema)

[Sandro M. <naa...@gm...>]

On 2/13/06, Tyler Close <tyl...@gm...> wrote:
>
> On 2/13/06, Sandro Magi <naa...@gm...> wrote:
> > Just out of curiosity, why didn't you go with a session-like persistenc=
e
> > model which transparently tracks changes to objects? For instance, the
> > Hibernate O/R mapping tool's session object maintains an in-memory copy
> of
> > the loaded object graph which is compared to that being saved by the
> client;
> > if any changes were made to an object, that object is scheduled to be
> > updated. In the web-calculus case, the whole object graph would need to
> be
> > reserialized if a change were detected.
>
> I wouldn't expect such a design to provide deployable performance
> characteristics. The whole object graph may consist of 10's of
> thousands of objects. Doing a complete serialization and compare on
> each POST request seems infeasible.



There are optimization techniques available. For instance, when
deserializing from disk, replace each interface with a dynamic proxy which
loads the real object on first access.

This situation is a little different from O/R since they can update
individual records, rather than have to reserialize the entire graph, ie.
they just serialize what changed. That sounds like it might be rather
difficult in this case.


> It's certainly less efficient than marking your objects dirty manually,
> but
> > it separates the persistence layer from the application logic. I'm just
> > wondering if simplicity, efficiency, ease of implementation, etc. were
> the
> > motivating factors in the current design, and whether you think the
> other
> > pattern would actually help/simplify at all.
>
> The motivating factor in the current design was to find the easiest
> model to write client code against which would provide deployable
> performance. Using explicit Var objects in the client code seems
> pretty easy to me and enables a high performance implementation.
>
> I think it's also important to compare the current design against the
> mainstream techniques. Transparent object persistence is a whole lot
> easier than programmer written persistence to a relational database.
>


Absolutely. No need for mapping files for one. Some people simply might
consider the tight coupling to org.waterken.db a downside is all.

Sandro