Just an FYI: "The other thing you can't do is define a column as part of a relationship AND include as a property on the same object. Both of these will result in a "duplicate column" error when it sends the SQL to the server for execution."
You can, actually. Let's illustrate the problem, though... Let's say you have a column, called 'whatever'. You define composition on that relationship, and not a property. That's fine, except when you try to do a TQL query, you can't use that property as a criteria. If I'm looking for whatever = :whatever, I'm going to get an error in the tql query when it tells me "whatever" does not exist. So it seems like the solution is to add a property, right? But if you add the 'whatever' property, but you ALSO add composition for Whatever, on save you'll get 'whatever is specified more than once'. Here's my solution: Define both the composition relationship AND the property definition. HOwever, your whatever property definition should look like this: <property name="whatever" column="whatever" ignore-insert="true" ignore-update="true" refresh-insert="true" refresh-update="true" /> This makes 'whatever' accessible via TQL and other methods, but it won't show up when saving or updating the object. That's how you have your cake and eat it, too. The ignores tell Transfer to ignore that property (even if you manually set it). Refresh, however, ensures that this property gets updated when you insert/update via a set/remove of the composition object. On Oct 17, 2:26 pm, Shawn <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
