On 2009-10-16 19.59, Kent Sølvsten wrote:
Maybe a compromising solution could be to separate persistence based on
the mixins in the EntityComposite? So the state for each mixin is stored
separately. The data in a mixin will probably tend to be used together,
at least in a good design.
And it should cause a lot less fragments than storing each property
separately.
I even think it makes sence conceptionally, since the basic atom in QI4J
is fragments, to store each mixin as a single unit. Not sure if any
technical issues makes it difficult/impossible.
That's what I did in SiteVision, where each mixin was basically
serialized separately and keyed by {id+class}. It works, but not
necessarily that much better.
Another point is, the EntityStore might want to get called the first
time a *part* of a composite is being accessed regardless of whether the
state of that *part* is already loaded or not, to allow it to learn
about usage patterns for the current usecase, even if all state for the
composite is currently eagerly fetched. Reducing the granularity to
mixins instead of properties/associations could reduce the number of
parts of a composite, and thus the number of callbacks a lot!
An entity is currently "loaded" in potentially 3 different steps: first
the proxy is created. Then, upon first state access the EntityStore is
asked for an EntityState. Then the actual state is retrieved. The
EntityStore could use information about the UoW when either the
EntityState or a specific property is loaded.
The drawback is off course, that each association/property will now need
to know which mixin it is a part of.
That in itself is not so hard, as the key will simply be the
package+class+method name, i.e. QualifiedName which we already have. One
issue is that if you move a property to another interface that *must* be
handled or the property is "gone".
On a sidenote: What is the proper way to handle partially loaded
entities when exiting a UnitOfWork? Should state not yet loaded be
lazy-loaded on exit, or should the client be prepared for
LazyLoadExceptions? If state is lazy loaded on exit, it will probably be
an incentive to use value objects.
Why would you want to do anything on exiting a UoW other than just drop
the state? Or are you assuming there's caching going on?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
