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)
>
>
>
>
> >
>


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to