On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou <[email protected]>wrote:
> Hi, Dan. > > We are really curious in practice, about how have you manage relationships > in Estatio. > Sorry not to reply sooner... I've actually been getting the Estatio source code up and running on github [2]. Yes, it's been open sourced! So you can take a look yourself at our efforts. (Would like to know if it builds ok for someone else, anyway). > - Have you declare for each one-to-many or many-to-many relationship, the > addToXXX, removeFromXXX, modifyXXX, clearXXX methods than can be generated > with the Eclipse templates? > > We've have done it for many, where the relationship is mutable. > If we don't declare the previous methods nor refresh an Entity, the > contents on the collection of dependent entities can be incorrect, for > example. > > Indeed, that is what we observed: that DN does not seem to actively manage the relationship. I seem to remember reading something to that effect also. I added in IsisJdoSupport [3] to provide the "refresh" method; perhaps you've used that. Having said that, doing some googling just now, I have found [4].[5], which basically says that DN *will* manage Sets (and thus, presumably SortedSets) but *will not* manage Lists. We have, over the last few months, been moving to using SortedSets exclusively; so it's possible that the issues that we saw were when we were using Lists. There is another factor here, though: DN will only maintain the relationship when it it is given some work to do, either (a) at commit time (framework controlled) or (b) at flush (application-controlled, using DomainObjectContainer#flush()). So as a bare minimum, even if DN does maintain Sets, you must still call flush. As I recall, Jeroen and I took the view that we would just use the addTo/removeFrom stuff always. > If Apache Isis would have an annotation similar to JDO's > @Element(mappedBy="xxx") nearly all one-to-many or many-to-many > relationships could be automatically managed in both sides, eliminating A > LOT of boiler-plate needed just for that. At least we have now automated > tests for testing them, with the bidir contract tests. > (Rather than introduce an Isis specific annotation, I would rather just teach Isis to understand the JDO annotation. But that's a minor detail ...) > > I understand (but can't imagine a concrete example) that automatically > managing relationships in some scenaries could not be desirable, so it > could be an Isis config option. > > But implementing the current "templated contracts" on the enhanced Isis > classes would be a perfect solution. The code on Entities would be just > "business code". In our classes, currently we are starting to have 75% code > for managing bidir relationships, and 25% business rules, in some case, > making it really hard to read. > > We could "simplify" all Domain Models telling that they are expressed > through Entities and Relationships between them, with business logic > (identical to the scientific concept of "Ontology" [1]. So why not better > support for Relationships, and not only for developing Entities ? > I hear what you are saying, but I'm wondering how this might actually be implemented. Right now Isis only gets to apply its semantics when the object is interacted with "through the UI" layer. At least in the Wicket viewer, all collections are immutable and so any manipulation of them is done in actions, ie programmatically and not through the UI layer. It could, I suppose, be done by wrapping the pojos (using the WrapperFactory), and have it apply the mapping; but that feels rather hacky to me. And, I don't think we can do the change in the bytecode enhancement process because that is as specified by the JDO spec, and is not extensible so far as I know [6] > > Please, what do you think? If you are not in favor of implementing managed > relationships, what are the reasons in order to properly understand it? > I can see the benefit, for sure... So, where I stand on this is: rather than get Isis to do this, perhaps all we need to do is to figure out a way to make JDO do the heavy lifting for us. All the JDO docs are a little confusing, it does seem to me that the combination of using Sets/SortedSets and calling DOC#flush() ought to do the trick. Could you do some experiments on that and report back? Cheers Dan > > Thanks in advance, > > Oscar > > > > > [1] http://en.wikipedia.org/wiki/Ontology_(information_science) > > [2] https://github.com/estatio/estatio [3] https://issues.apache.org/jira/browse/ISIS-386 [4] http://www.datanucleus.org/products/datanucleus/jdo/orm/relationships.html [5] http://www.datanucleus.org/products/datanucleus/persistence_properties.html [6] http://db.apache.org/jdo/enhancement.html
