Hi Cesar. As Dan points out, m:n relationships are only useful when the "link" does not have associated attributes or domain logic associated. We have use cases similar to yours. Many times there's a hidden "entity" there with its own meaning, and just sometimes we simply model it as an m:n relationship.
HTH, Oscar > El 9 oct 2015, a las 1:38, Cesar Lugo <[email protected]> escribió: > > 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 >
