I am not sure I can follow your text well enough (code would be better). 1. @Aggregated annotation on associations will ensure that referenced/aggregated entities are removed along the aggregate automatically by the UnitOfWork.
2. Removal of entities referenced should happened in a a coordinated manner and not "ad hoc". Sometimes that means that the removal should be done "on" the aggregating entity, and sometimes it mean that you need to orchestrate the events taking place. If you give a tad of code to show what you are trying to say, perhaps easier to grasp. Cheers Niclas On Tue, Jun 14, 2011 at 12:13 AM, Frank Grimm <[email protected]> wrote: > > Rickard, many thanks for your reply, the Log/GenericConcern works fine! > > I've got another question related to event notifications: updating > references when Entities are removed. > > In order to get a feeling for Qi4j Entities and the UoW, I created two > Entities 'A' and 'B' and connected 'A' to 'B' via an Association. When B b1 > referenced by A a1 was removed from the UoW (calling uow.remove(b1)), then > accessing b1 via a1.b().get() of course fails. > > I'm wondering how to remove a1's reference to b1? Should a1 listen to > REMOVED events send when uow.complete() is called and then remove the > reference to b1? Or should/can this be done in a more generic way by getting > all Entities referencing b1 and remove those references? (Maybe updating > references is a non-issue when database EntityStore is used, because they > are automatically removed then, but I'm using MemoryEntityStoreService and > its unit test indicate that references are not automatically updated.) > > Many thanks, > Frank > > > Rickard Öberg-3 wrote: >> >> On 6/10/11 1:18 , Frank Grimm wrote: >>> I'm trying to add SideEffects to Properties of Composites so that I can >>> trace getting and setting of property values. In order to get a feeling >>> for Qi4j in general (I'm a Newbie) and SideEffects in particular, I >>> copied LogPropertyAccess and LogPropertyChanges from >>> org.qi4j.runtime.property.PropertyTest together with the Company and Co. >>> composite to my test application: >> <snip> >> >> I just verified in PropertyTest that my previous email works. Here is >> the final code I used for the concern: >> @AppliesTo( PropertyMixin.PropertyFilter.class ) >> public static class LogConcern >> extends GenericConcern >> { >> @Override >> public Object invoke( Object o, Method method, Object[] objects >> ) throws Throwable >> { >> final Property property = (Property) >> next.invoke( o, method, objects ); >> >> return new ComputedPropertyInstance(property) >> { >> @Override >> public Object get() >> { >> Object result = property.get(); >> >> System.out.println( "Property " + >> property.qualifiedName().name() + " accessed with value " + result); >> >> return result; >> } >> >> @Override >> public void set( Object newValue ) throws >> IllegalArgumentException, IllegalStateException >> { >> Object current = property.get(); >> >> property.set( newValue ); >> >> System.out >> .println( "Property " + property.qualifiedName() >> .name() + " changed from " + current + >> " to " + newValue ); >> } >> }; >> } >> } >> --- >> The main modification that one would like here is that it should be >> possible to register PropertyChangeListeners to an individual property >> instance. Putting a PropertyChangeSupport instance into the metainfo >> would make the most sense I think, but the question is how to get a new >> instance per property instance, instead of one for all property >> instances. This I don't yet know how to do. >> >> With the above it would still be possible to generate events that are >> broadcast in the application (using something like >> http://java.net/projects/eventbus), which listeners could then pick up. >> In my own apps I have found that pattern to be more useful anyway, in >> order to get property changes in one place to easily affect a completely >> different panel. >> >> /Rickard >> >> _______________________________________________ >> qi4j-dev mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/qi4j-dev >> >> > > -- > View this message in context: > http://old.nabble.com/SideEffects-for-Properties-tp31811808p31835648.html > Sent from the Qi4j-dev mailing list archive at Nabble.com. > > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- 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
