Glad I could help. I just started using Transfer ORM about 2 months ago, so you are bringing up issues I've already had, crossing ground I've already crossed.
"So this would do away with the need for the circular onetomany/ manytoone references, which is a benefit, but what am I losing by setting it up this way?" Only you can answer that question. Look, as someone who took advantage of Transfer ORM to create composition relationships for every single entity in my db and ended up dialing back a few of them later--composition is great. But does absolutely everything in your db NEED composition? The answer is decidedly NO. Now, but taking away composition, you'll have to set IDs directly. Ie., setbookID() rather than setBook(). This can be a little confusing as far as intermixing your logic, but eventually you'll remember, "Oh yeah, no composition in this one...I guess I'd better set the IDs." On other occasions, I have killed myself struggling with a way to maintain composition to avoid transfer ORM errors or other general weirdness that can sometimes result....in the end, the simplest fix was often to remove the composition, especially once I took my ego out of it and looked at the problem objectively. Same thing goes with queries. TQL is very powerful, and has a lot of great features--but it will never be, CAN never be as versatile as SQL. If you have complicated reporting you need to do, I would say that Transfer ORM isn't the tool to use for something like that. What Transfer really does best is automates the painful work of manually developing composition relationships (and it's SO incredibly handy), and provides data caching. You'll need both of these things, but not everywhere. On Oct 17, 11:30 am, "Stephen Moretti" <[EMAIL PROTECTED]> wrote: > Hi Shawn, > Thanks for your reply. > > 2008/10/17 Shawn <[EMAIL PROTECTED]> > > > > > Another thing to note (and I could be wrong about this), I have never > > noticed a manytoone relationship creating any generated methods for > > the 'linked' object, only for the object in which manytoone is > > defined. > > No - you're right - it doesn't usually - however, I thought perhaps the > composite id would generate something, so that its accessible to its parent > objects. > > > However, onetomany adds methods to the 'child' table called > > getParentxxx() Example: theme.getParentBook() would return the book > > that 'owns' the given booktheme. Which would sort of make the > > composition relationship for getBook() obsolete. > > hmm yeah... > > > > > > You can avoid recursion issues by setting lazy="true" on your > > > manytoone composition relationships in the composite (as I did > > > above). > > Ah... that might explain why I got getMemento loop errors earlier... I put > the lazy="true" in the book object rather than in the booktheme. > > With this relationship, you can pull up an array of all of> > the themes > applied to a book with book.getThemeArray(); Since you > > > have a composite key, it appears you can have multiple themes applied > > > to a book. > > That's correct. (And a "star rating" with each theme) > > > > > > Also, if you don't care about composition on your composite key, you > > > can also reference property instead instead of doing a composition > > > relationship. ie., > > > > <object name="booktheme" table="booktheme" > > > decorator="contentobjects.BaseBean"> > > > <compositeid> > > > <property name="bookID" column="bookID" /> > > > <property name="themeID" column="themeID" /> > > > </compositeid> > > > <property name="StarRating" type="numeric"/> > > > </object> > > So this would do away with the need for the circular onetomany/manytoone > references, which is a benefit, but what am I losing by setting it up this > way? > > Thanks again for your help. > > Regards > > Stephen --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
