Nando, We've done very much the same thing in most cases... however it has lead to conflicts and confusion in some cases because things like <property name="userID" /> were reasonably converted to relationships and broke other code that had to then be fixed. This was in part because there's more than one dev on this project and it's our first major project with Transfer, so we had some of our own kinks to work out. OTOH, even working on your own it can be really hard to remember which properties you used as properties and which ones you are converting to relationships as you get further and further in.
So I guess I'd suggest a similar approach with the proviso that you need to document which properties are "safe" as relationships and which ones aren't... J On Jan 9, 2009, at 5:28 AM, Nando wrote: > I might have something to add to this discussion in regards to > taking a practical approach toward relationships in Transfer. > > I'm working on quite a complex application where I could construct a > variety of very complex relationships in Transfer - if I decided > that every relationship in the application should be modeled in > Transfer. But that's not how I'm handling it. Instead, I'm only > constructing the relationships that I need to handle a particular > transaction with the database in Transfer. ... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
