Hi Dan. Yes, I'm receiving old messages also...
That's related to DN, not to the EventBus. The problem is not with the semantics of the operation, but with it "eating" a database exception and returning simply false instead of throwing it to be catched anywhere. The point is that at finish the user cannot be sure that the operation is retiring false only because the set contained the object. There's another case when it returns false: a database exception was thrown so the object has not been persisted to the database. HTH, Oscat Disculpa que sea breve. Enviado desde mi móvil > El 16/05/2014, a las 16:39, Dan Haywood <[email protected]> > escribió: > > On 16 May 2014 09:43, GESCONSULTOR - Óscar Bou <[email protected]>wrote: > >> >> Hi all. > Hi Oscar, > this has only just come through to my mailbox, even though you sent it ~5 > hours ago. I've also been having a variety of commit messages etc delayed, > some by as much as 5 days(!). Not sure if the problem is at my end or at > ASFs (but I suspect perhaps the latter...) > > Have you noticed any delays? > > > >> I'm implementing the new support for automatic simple and collection >> properties change events (@PostsPropertyChangedEvent, @ >> PostsCollectionAddedToEvent, @PostsCollectionRemovedFromEvent) and the new >> mechanism works really nice :-)) >> >> I've just initially forgot to register the service as an event subscriber, >> thinking that it was unnecessary. So perhaps auto-registering the service >> when "detecting" the guava's @Subscribe annotation would be a good >> enhancement. > OK, I'll raise a ticket. > > > > >> I've found that an exception thrown by DN has been hidden by Isis. > Just so I'm clear ... this is unrelated to the event bus stuff, correct? > > > > >> The root-cause is because I have not properly defined the @Inheritance >> mappings correctly, but the relevant thing from Isis perspective is that DN >> does not throw any exception if, on a collection annotated with @Join, the >> "add" is not properly executed. >> >> >> When the >> >> this.getAggregatedServices().add(service); >> >> >> Is called, the following exception occurs: >> [snip] >> But DN does not throw any exception. It simply returns false when exiting >> the >> >> this.getAggregatedServices().add(service); >> >> method ... >> >> The DN implementation is on [1]. >> >> So seems that it's mandatory to evaluate the result of "add" !!!! > I don't think this is a bug, I believe that DN is conforming to the > semantics of Set#add(...). I've just mailed Andy @ DN for clarification. > > > >> I understand that an ApplicationException should be raised in all cases. >> What would be a convenient "idiom" we can all use? > From the Javadocs: > > Adds the specified element to this set if it is not already present > (optional operation). More formally, adds the specified element e to this > set if the set contains no element e2 such that (e==null ? e2==null : > e.equals(e2)). If this set already contains the element, the call leaves > the set unchanged and returns false. > > If it returns false, it means that the element is already in the set; the > post-condition is the same. So the idiom is simply to ignore the return > code, it doesn't matter if true of false is returned. > > > Of course, this relies on a correct implementation of equals(); one option > is to use Isis' ObjectContracts helper class. > > > HTH > Dan > > > > >> >> Thanks, >> >> Oscar >> >> >> >> >> >> >> [1] >> https://github.com/datanucleus/datanucleus-core/blob/master/src/main/java/org/datanucleus/store/types/wrappers/backed/TreeSet.java#L719 >> >> >> >> >> >> >> >> >> >> >>
