On Mon, Aug 1, 2011 at 6:06 PM, Rickard Öberg <[email protected]> wrote:
> The first is if you have Entity A with association to Entity B. If B is > removed, then Entity A is essentially invalid, and cannot really be fixed. > There will be all sorts of loading errors. If B however could be loaded just > as a reference, but which creates errors on calls, then A could be "fixed". Really? Is that because you must have the EntityB instance to be able to remove it from association? Because, AFAIR, the associated entities aren't loaded until requested, right... More importantly; If B is removed from store and A has Association<B> b(); then is there really any valid resolution at all (note; not @Optional)?? Even assigning a fake one, seems breaking the semantic contract. I.e. it seems more realistic to not allow delete() without "strong reference" semantics a la JVM. The mechanism for that can get tricky in the non-aggregated case, but I think we can come up with clever ways to get control who has reference to entities, how they are accessed, removed and so on, that are not "conventional wisdom". Got no ideas at the moment, though... > Secondly, I'm adding Associations to Values. Essentially, if you declare an > Association in a Value, then it is resolved upon get() against the current > UnitOfWork. If no UoW is active, then either an exception could be thrown > *or* a similar "fake entity" could be used, just as a marker that can be > passed around for reference purposes. Yes, that sounds reasonable. -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
