Thanks Brian.. your response is in line with my general understanding of the o2m vs m2o relationships, and I was by no means blaming Transfer for anything. I think I hijacked the thread and took it off topic, but your post reminds me of a good blog I read and must have forgotten about o2m vs m2o... maybe it was from you or maybe it was Brian Rinaldi, IDK.. either way, I clearly remember reading a similar relationship guidance for transfer models.
But what motivated me to deviate from that and possibly even missuse the o2m, as you have pointed out, was this particular case: Lets say I am a processing job shop, I receive multiple lots of different types of object made of different types of materials manufactured by different companies and sent to me from different customers every day, of every week, of each month, of every year. I process these parts, and then I ship them back, and collect payment.. these "parts" are complex and so is my "process".. I have many customers.. some of my customers have 10,000 different parts, with different revisions, and they will request a quote or send these parts in each revision for me to "process".... so I said to myself.. these are tightly related relationships.... this isn't a user has an account type.. in a "known" system where things can be defined as m2o or in some other way..... and i thought: Self, A customer has many parts , then I thought... Self, this part belongs to this customer. but then I found out that a customer generated by transfer doesn't know diddly about the parts which it could have when it's defined as m2o .. then I said "Self, WTF am I to do?" Is this a cust->part = o2m or a part->cust = m2o? To find out if I have in fact taken the wrong approach with my TIBO work-around is exactly why I'm here.. I don't know enough about this to go-it-alone... so all of your input matters, and I appreciate it! so, lets get back to my case and say, "a customer has many parts".... but lets say I never really 'ask' transfer to give me *all of those parts only 1 of them when requested via lookups done with querys generated via TQL... in this TIBO I inject a cloned empty transfer object of that concrete type.. This gives me a new, technically decorated "TransferObject" which I can work efficiently with in my UI, Controller, Service, Gateway, Transfer.. it is a "vitural" transfer object which I re-populate via a cached query generated via TQL, or sql, or a file or directory query.. and then I override some of base transfer properties to "simulate" a real transfer object.... so far this is working prety nicly as a o2m with 10k+ objects using 1 cfc, not 10,000+... FYI my current dev box is running cf 8.0.1 | jvm 1.6.12 @ 1.3gb heap 256perm | transfer 1.1 | cs 1.2 | cb 2.6.3 | majik 0.7 | jquery 1.3.2 on IIS 7 / WIN7x64 - Intel QuadCore @ 2.6ghz w/8gb ram. although I understand that I can't assume that it won't happen, I am NOT actually ask transfer to generate 10,000 cfcs in that relationship for me while still getting the o2m transfer functionality, performance, and ancillary support functions I need when and where I need them.. I don't know if the above context helps you see my motivation in a different light.. but it's also worth noting that In general, as a rule of thumb, transfer is very good at doing it's job... maybe I just have problems understanding some of my percieved special relationships.. the only thing I could say is that maybe o2o or bi-m2m support would could helpe creative developers come up with other ways of dealing with my issue. I think with the o2m+TIBO, I have attempted to beat the system by having all of the transfer functionality that i need, when and where I need it.. even if i'm designing around my own created issues with the miss-use of a relationship.. I learning something. Thanks & have a good weekend all! -adam On Mar 13, 4:07 pm, Brian Kotek <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
