Re: [Hibernate-devel] collections

[Doug C. <de...@fl...>]

> Well, I've decided I'm going to have to "refactor" the collection code. It
> turns out that we really *do* need to be able to do things like clone the
> entire state of a collection + fully diff the state of two collections. I
> liked my shortcut method of dirty checking for a while, but now its
> becoming a real hassle to do other things where I really need to capture
> the whole state (eg. caching). The codebase is now full of ugly workarounds
> for collections because they don't have this ability.

I liked your shortcut method of dirty checking, also. It was a big
performance win, I suspect, and I wonder if you are trading it away
for a feature (caching) of dubious value for some types of collections.

I hope you will keep "deep lazy collections" in mind in the design.
Here are some things to consider...

Where are cloning and diffing necessary?
Is it possible for an application to avoid it (e.g., by not assigning
a collection to more than one persistent property, and/or by not
caching the collection)?

Can a deep lazy collection use other techniques to avoid fully
materializing the collection, e.g., version numbers?

> This means there will be no new features or bugfixes from me until this job
> is finished. cross-transaction caching is sort of implemented, but I'm sure
> there are problems there.

I have watched other object database projects founder on caching
implementation problems. There is *no* easy way to do it. In order to
support multiple transactions you *must* have multiple versions of
objects materialized. ODMG pays lip service to this; JDO defines
various kinds of object equality to support it.

One of the reasons I was drawn to Hibernate was its simplicity, and
its dependence on the JDBC and database layers for the capabilities
they provide, such as transactions. JDBC and the database also (can
and sometimes do) provide caching. I liked the fact that Hibernate
"bit the bullet" and supported materialization of an object
independently in several transactions (sessions). It seems to me that
there are only two caching strategies consistent with this: (a) let
the database do it, and/or (b) a separate cache per session.

> What I will do is add a method clone(Object x) to the Type interface. Then
> all mutable types will be expected to implement this. (immutable types can
> just return x).

Hopefully, clone() can do a shallow clone for deep persistent
collections? (e.g., using "allocate on write") I guess this
depends on what clone() is being used for.

> I will change the implemntation of equals() for collections to diff the
> object graph instead of doing ==.

Of course, == implies equals(). Then there's JDO equals(). But I
assume this is for dirty checking?

e