Shawn is correct... o2m is the only relationship type that generates methods on the child object.
For a complete listing of the generated methods available in a TransferObject, check this page: http://docs.transfer-orm.com/wiki/Generated_Methods.cfm As for adding the relationship to both objects, I haven't ever seen this work as expected... though maybe I'm misunderstanding something. What I've seen is that even with different aliases on the object definitions, when the save() and update() methods are called it boils down to having duplicate columns specified in the SQL which won't run as a result. Lazy loading makes the reads work acceptably, but bidi relationships aren't supported, so I'd strongly discourage that option. 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. There are a couple things you can do, though, to get to the parent from the child if you're using m2o or m2m relationships: 1) To get an array of related parent objects, use a custom sql statement in an actual cfquery to pull the appropriate IDs for the parent object based on the related object's ID and loop over the query, calling arrayAppend (getTransfer().get ("ParentObject",queryName.parentId)) for each one. 2) #1 also works for fetching single records, without looping over it. 3) Rework your object definitions to define one-to-many objects on theme and book... that way you can call theme.getBookThemeArray() and BookThemeArray[1].getParentBook() or .getParentTheme() from a book theme. That should give you a nice clean path from book to theme and still allow you to use each object independently as well. The other serious suggestion I'd make is that you create one decorator CFC per object (so you'd have contentObjects.Book, contentObjects.BookTheme, and contentObjects.Theme) and then add extends="contentObjects.BaseBean" to each of them, allowing you to have a separate decorator class defined per object definition in the Transfer config, and yet have a common ancestor for each that contains all the things that are truly common across all beans (for example, implementing your own Bean.save() method, not that I like that idea, but it's a handy example). Having only one decorator class will eventually get to be cumbersome... HTH, J On Oct 17, 2008, at 11:04 AM, Shawn wrote: > > 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. 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
