I'm advising against it because it's the incorrect use of oneToMany. Technically it's a performance issue, but that's not Transfer's fault. It's an issue of using the wrong kind of relationship for the situation.
Because a oneToMany creates a parent-child relationship, if you have 10,000 related objects in the collection, you're absolutely going to have major, major problem. Whether you use lazy or proxied objects isn't going to make a difference. There are internal situations where Transfer will check things about the relationship such as determining if an item is already in the collection. That means loading ALL 10,000 of the related objects. With proxy objects it may load 10,000 proxies (maybe Mark can confirm), but that's still a gigantic number of CFCs being instantiated. In essence, don't assume anything about how or when Transfer is going to trigger a load of all 10,000 of those children. If you have a OneToMany, and one side of that relationship has too many objects (and by too many, I mean any number that is more than you would want transfer to create in one shot), then don't use a OneToMany. Use a ManyToOne, i.e. person.setCompany(company). OneToMany, is meant for very specific, tightly related relationships. For me, that means something like 10 or maybe 100 related objects at most. The actual number is up to you but following my own advice, I would not really want Transfer to be creating more than 100 related objects. For example: A User has a BillingAccount. If your business model is such that most BillingAccounts have one User, or if most BillingAccounts have only a few Users, then use a OneToMany if you wish. i.e. User.setParentBillingAccount(). However, a User also has an AccountType. AccountType is probably quite generic and could be associated with thousands or tens of thousands of Users. In such a case, do NOT use a OneToMany. Use a ManyToOne, i.e. User.setAccountType(). On Fri, Mar 13, 2009 at 12:16 PM, Adam Drew <[email protected]> wrote: > > @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 > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
