Hi Dan, First of all ... Wow! is this not only the fastest Domain Driven development framework , but also the one with the quickest response support team? :) Second, I am honored to get a response from you, I have read a lot about your great work and commitment to Apache ISIS and Naked Objects, and excellent tutorials, demos and add-ons. Congratulations!
So I will work on your suggestions and let you know. Thank you so much! Cesar. -----Original Message----- From: Dan Haywood [mailto:[email protected]] Sent: Thursday, October 8, 2015 5:58 PM To: users Subject: Re: Apache ISIS relationships Hi Cesar, and welcome to [email protected] mailing list. A few thoughts on this... ... first suggestion: you ought to be able to map this relationship as an m:n, rather than as two 1:m and n:1 relationships. I must admit I don't do that in Estatio, but Oscar has done it I believe, because he included the m:n relationship in the set of templates he developed for IntelliJ / Eclipse [1]. I think the ones you want are called "iscs.jdo.mn.ub.p" (Isis JDO m:n parent) and ""iscs.jdo.mn.ub.c" (Isis JDO m:n child). There's also info on m:n relationships at the Datanucleus site [2]. So far as possible Isis isn't responsible for persistence, that is delegated to DataNucleus ... so if it's a feature of DN then it *should* "just work" in Isis. ... second suggestion: if you do decide to have a link item table, then you could use the foreign references to Vendor and to Item, eg ObjectContracts.compareTo(this, "vendor", "item"). I'm not sure I recommend this, though, because it will require the referenced objects to be loaded in order to do a comparison, which could impact performance ... third suggestion: do a bit more domain modelling. I suspect that, over time, you will find attributes/responsibilities that live on the link entity, and it probably has a more meaningful name than just "VendorItem". If it represents the fact that a vendor can sell an item, then presumably it has a cost, and perhaps a discount, and maybe a target profitability, and perhaps a wholesale supplier from which the vendor purchases it in turn. This is the reason we have no m:n relationships in Estatio ... there's almost always something interesting to say about that relationship. HTH, Dan [1] http://isis.apache.org/guides/cg.html#_cg_ide-templates [2] http://www.datanucleus.org/products/accessplatform/jdo/orm/many_to_many.html On 8 October 2015 at 23:27, Cesar Lugo <[email protected]> wrote: > Hello again! > > > > I have created an Apache ISIS prototype application, and in some cases > I need to have some Domain Entities that do not have any properties > other than references to other Domain Entities, for example, used just > to build Many-to-Many relationships among 2 Domain Entities (I am not > using foreign keys). For example, a Vendor can sell us many Items, and > an Item can be purchased by many Vendors. So I define a VendorItem > entity, which has a property to reference Item and Vendor entities > within it. Everything works fine, until I get to the collections > (using SortedSet) on Item and on Vendor to list all VendorItem > relationships either from Item or from Vendor. In that case, because > VendorItem needs to be implemented using a Comparable class, it > requires a field for the CompareTo method. The only way I have been > able to work around it is to declare a property (vendorItemId) that I > don't really need, and populate it manually every time I create a new > VendorItem relationship. Is there a way to avoid using such a > (vendorItemId) > property, or use the automatic "id" field generated by the JPO > idGeneratorStrategy.IDENTITY column = "id" annotation?. Or, is there > any other better way to manage Many-To-Many relationships using Apache > ISIS and JPO? > > > > Cesar. > > > > > > > > > > > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
