7939 Posts in 1472 Topics by 944 members
|Go to End||Next >|
5 September 2009 at 4:49am
Umm, before I go any further, did you guys know that you don't have to define $belongs_many_many? I have at times mistakenly defined both as $many_many and it works fine.
Maybe try that first?
I never got the whole belongs_many_many thing, anyway.
5 September 2009 at 4:57am
I have actually tried that and it kind of works.
The problem with defining many_many on both sides is that you end up with two separate independent linking tables so the relationship ends up being one sided.
The functionality I'm after is having a DataObjectManager on one side (the ProductPage) and then linking that to a SoftwarePage. When editing a SoftwarePage I might change my mind and want to change that relationship. As things are today you can either represent the relationship from the belongs_many_many side with a checkBoxSetField or you would have to save the SoftwarePage and then go to the ProductPage in question and change the relationship there.
Looking at the code for ManyManyComplexTableField it looks like they planned on it working the way I have described but someone borked the code for finding the linking table from the belongs_many_many side.
If you go for many_many on both sides relating a ProductPage to a SoftwarePage won't make a SoftwarePage related to a ProductPage since the relationships will be independent of eachother.
10 September 2009 at 11:37am
Really appreciate your work on this. I have been thinking, and I wondered if it was possible to NOT call 'getCMSFields_forPopup()' when the only permission that is set is 'show'. Because, if you have a page-to-page relationship you probably wouldn't need to add or edit the information from the dataobjectmanager. Let me know what you think.
4 February 2010 at 3:32am
UncleCheese will Smurkas code ( post268318 ) be included in the next version of ManyManyDataObjectManager? It solved the issue for me and allowed me to use ManyManyDataObjectManager at both sides of the relationship.
Also in possibly an unrelated issue I found that using the name of the class as the array name brakes things:
// This doesn't work
static $belongs_many_many = array(
'Species' => 'Species'
// This does work
static $belongs_many_many = array(
'ProjectSpecies' => 'Species'
4 February 2010 at 3:59am
I don't think that code is ready to be included partially since you seem to have found a bug I'll have to take a look at and because it kind of breaks the way things normally work.
Fixing the bug is doable but I'm very unsure if there is a satisfactory solution to the infite loop since that's simply how DOM/Complextablefield is built. They all have the functionality of defaulting to getCMSFields() and this fix breaks that functionality in a pretty huge way.
Since this seems to be a pretty rare scenario that break might be kind of acceptable but that decision is up to UncleCheese. IE we would have to inform people that using DOM on the belongs_many_many side means you have to setup separate popup-getters, otherwise everything explodes.
9 February 2010 at 12:33am
Thanks Marijn. This solved an issue I was having.
9 February 2010 at 12:51am Last edited: 9 February 2010 12:52am
Nice to see that the code is getting some use.
I haven't had the time to look at the problem you reported Martijn but I'll hopefully get to it in the next couple of days and see if I can figure out what goes wrong when you use the same name as key/value.
I just wanted to add that there is one more scenario where this will break rather messily and that is when you have several many_many relations to the same object, for example
public static $many_many = array(
"Scenes" => "Scene"
"MoreScenes" => "Scene"
This is probably a pretty rare scenario but if it applies to anyone trying this fix then know that this will break it. The big problem here (which I don't think there is a real solution to within the boundaries of how this works today) is that there's no way for the belongs_many_many class to figure out which one of the two relations above is the one that applies and thus it can't reliably find the correct relationship table.
If there's just one many_many relationship to a class then it works, if there's more it doesn't. I am going to have a look at how (or if) SilverStripe solves this with it's getters, if we're lucky there is actually a solution to this somewhere in the code.
27 January 2011 at 6:19am Last edited: 27 January 2011 6:20am
It looks like the 'belongs_many_many' is still a problem. Iv done a quick hack to stop FormScaffolder building anything on these types of relationships and submitted a patch here;
|Go to Top||Next >|