On 8/1/11 19:02 , Niclas Hedhman wrote:
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...
Hm... now I'm not sure actually. Need to test this, to know what the
cases are. I remember having a ManyAssociation with a removed entity and
it was a pain to fix it.
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...
Right, the case suggests that the domain model *is wrong*, i.e. you are
keeping references which shouldn't be there. Most of the time, these
days, I actually don't remove them at all, but instead just mark them as
deleted (I have a "Removed" interface/mixin). When you actually *do*
remove them, there needs to be a way to clean it up afterwards.
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.
I think this will REALLY simplify UI stuff. Most of my REST commands
receive and return Values with EntityReferences in them, and if they
could be validated and turned easily into real references, that simplify
things.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
