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. For instance, the job of editing complex records (that have multiple layers of one to many relationships in the database) is broken up into individual screens or popups to reduce the complexity for the user. This allows me to construct (and deal with programatically) only snippets of the relationships in Transfer. Effectively, I only construct the part of the relationship needed in a single view, or view/persist cycle. So in practice, the relationships are implemented on an as needed basis as the application is coded, because I, like my users, can only handle so much complexity in one go. Nando On Fri, Jan 9, 2009 at 12:29 AM, Jared Rypka-Hauer <[email protected]>wrote: > > Doug, > > I have developed a strong distaste for m2m joins and am strongly > encouraging people to avoid them at almost all costs. They may be > convenient in the short term, but in the long term you end up > implementing a whole lot of hassle because, at the very least, an m2m > is not easily traversed from either side of the relationship. > > What I would recomment, if I were you, is 2 o2ms. This gives you the > ability to do something like this: > > <cfset newUserPref = getTransfer().new("UserPref")> > <cfset UserPref.setParentUser(User)> > <cfset UserPref.setParentPref(Pref)> > <cfset getTransfer.save(UserPref)> > > You can also easily add simple, straightforward convenience methods > like User.addPreference() and User.getPreferencesArray(), or > Preference.addUser() and Preference.getUserArray(). This way you can, > using simple and obvious code, simulate a lot of the ease of m2m joins > but, at the same time, you can do crazy things like add a dateAdded or > addedByUser or an enabled column, to the join table, making it easy to > store some data in that intermediate table that you cannot under any > circumstances access using m2m joins. > > As for the "if you're using m2m" comment below, what that basically > means is something like this: > > set User = transfer.get("user"id) > set currentUserPrefs = User.getPreferencesArray() > > loop over (form.commaListOfUserPrefsForUser) { > if (user already has the pref) do nothing; > if (user doesn't have the pref) > User.addPreference(transfer.get("Preference,idFromTheForm)) > if (if the user has it but it's not in the form field) > User.removePreference(transfer.get("Preference,idFromTheForm)) > } > > Transfer.cascadeSave(User) > > And by doing so you only have to worry about adding/removing > properties to the user and the m2m "magically" handles the actual > adding, deleting, or updating in the table in the DB. > > HTH, > J > > On Jan 8, 2009, at 2:13 AM, Doug Boude wrote: > > > Hi all. Probably old hat to some of you (actually I'm hoping that it > > is), but I'm needing a solid little snippet illustrating/ > > representing a blurb I found in a Transfer group post from back in > > July. The scenario is that I have two tables who have a many to many > > relationship... users to preferences. I edit the preferences for a > > given user and want to update the junction table's records (remove > > the ones that are now irrelevant, leave the good ones alone, add > > ones not currently in existence). I understand that Transfer can > > automagically do such things for me, but I can't seem to find the > > right button to push. Anywho, here's the blurb I'm referring to: > > > > "If you have the collection from one object -> another > > Why not just loop around your collection of objects, and then do a > > check - if it's meant to be there, keep it, if it's not,delete it,and > > if it's not there, add it. > > Doesn't seem like that big an issue. > > If you are using m2m, then it manages this for you. " > > > > If my hungry little eyes could see just one simple example of this > > "not so big issue" in action, I would be MOST greatful! :) > > Hypotheticals and non-tested snippets welcome. > > > > > > Doug :0) > > > > > > > > > > > > > > > > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
