Many Thanks Dan and Jeroen! Great beginning of the week. Estatio and the new BDD support released! Congratulations and many thanks to Jeroen and you.
I'm in a hurry and have not yet finished to build Statio but there was a dependency problem on the web app related to the ms SQL server driver, which must be manually installed and it's not commented as in the QuickStart. Tomorrow I plan to fully test the Estatio release. Thanks again, Oscar Enviado desde mi iPhone El 15/07/2013, a las 13:42, Dan Haywood <[email protected]> escribió: > 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
