@Brian, Are you advising the use of a manyToOne instead of oneToMany with large collections strictly because of transfer performance issues? Or is there some other relationship guidance behind that?
I understand the potential for issues with only having oneToMany relationships.. but so far, I have been working on a fairly complex model with over 200 objects.. some of those objects have oneToManys with collections of 10K+, I use lazy, proxied, oneToManys on those transfer objects. Then i use a TIBO for displaying, paginating, or filtering those large collections where performance issues arise... It's not done yet, but honestly I'm very pleased with the overall functionality and performance of this approach thus far, however the TIBO is not a part of the transfer.... so i understand that, as a best practice with a strict transfer implementation.. that a manytoOne maybe the best route for performance concerns until future features are added... However, The TIBO is a topic i had brought up in the past on the list.. and is something I plan on posting a component someplace one day for anyone here who is interested when I can get the implementation cleaned-up and stable enough for what I need to do with it.. hopefully it works for someone other then myself. I guess I'm just curious if I'm missing some caveats about the oneToMany+TIBO approach I've been spending some time on... I have have not yet worked it out on manyToOnes.. but plan on doing so... and I would be interested to hear your input on this topic in regards to oneToManys vs manyToOnes... Regards, Adam On Mar 13, 8:15 am, Brian Kotek <[email protected]> wrote: > How large is "a large number of objects"? What you probably need to do is > revisit the relationship since you shouldn't be using oneToMany in > situations where there are a large number of objects. Use manyToOne. > > But you can override the configure() method in the Decorator. From the > documentation: > Setting up values in the Decorator > > configure()<http://docs.transfer-orm.com/html/transferapi/transfer/com/TransferDe...>on > the TransferDecorator will be run when the object is first created. > You > can overwrite this when you implement your own Decorator CFC, and is a > perfect place to set default values for your Transfer Object. > > It should be noted that configure() is run *before* the object is populated, > and therefore, any values it sets will be overwritten by those retrieved > from the database. > > You might also look at using the Transfer Proxies for this relationship > instead of the real objects. > > On Fri, Mar 13, 2009 at 5:33 AM, John Whish <[email protected]>wrote: > > > > > Hi, I know there is the configure method of a decorator which runs > > before the object is populated. Is there a method that runs after the > > object is populated? I have a onetomany relationship which creates > > lots of objects which are basically a "name-value" pair, which could > > have a performance impact (the cache has to run out of space at some > > point!) so I'd like to parse these into a simple struct which is > > stored in the User object and then destroy all the onetomany objects. > > > Transfer.xml Snippet: > > <package name="member"> > > <object name="User" table="USERS" decorator="com.model.member.User"> > > > <id name="UserID" column="user_id" type="GUID" > > generate="true" /> > > <property name="Email" column="user_email" type="string" > > nullable="false" /> > > > <onetomany name="UserAttributes" lazy="false" > > proxied="false"> > > <link to="member.UserAttributes" column="user_id" > > /> > > <collection type="struct"> > > <key property="Key" /> > > </collection> > > </onetomany> > > > </object> > > > <object name="UserAttributes" table="USERATTRIBUTES"> > > <id name="UserAttributeID" column="userattribute_id" > > type="numeric" > > generate="true" /> > > <property name="Key" column="userattribute_key" > > type="string" /> > > <property name="Value" column="userattribute_value" > > type="string" /> > > </object> > > > </package> > > > Thanks! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
