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

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

On 2/10/06, Tyler Close <ty...@wa...> wrote:
>
>
> When I first built the persistence interface, I was expecting that the
> common case would be an object containing many mutable variables. In
> this case, a persistent data class containing these variables would
> need to be defined, and a second class creating the public interface to
> that data class would also need to be defined.




Just out of curiosity, why didn't you go with a session-like persistence
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.

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.

Sandro