RFC Versioned many_many

[Damian Mooyman]

Hello all, I'm looking at gathering feedback on a feature we would like to develop for silverstripe 4.0.0 alpha3.

In order to support versioning of many_many relationships we are looking to implement versioning through a versioned has_many relationship. This is sometimes called "has many through" relationship, which has an equivalent in ruby on rails http://guides.rubyonrails.org/association_basics.html#the-has-many-through-association.

The advantage of this is that you can apply any extensions you like (such as Versioned) to the mapping table class, whereas many_many_extraFields wasn't backed by any real extendable objects. It would also open up the option to support translatable or subsite specific relations.

Rather than developing a new syntax or separate configuration for dataobjects, I've been looking at ways we can extend the current syntax for many_many.

I've put up a few options at https://github.com/silverstripe/silverstripe-framework/issues/5615, and am accepting suggestions for other ideas.

Please let me know if you have any feedback. :)

Kind regards,

Damian Mooyman

[Roman]

Seems like a good approach, when you have a data-model that fits the has-many-through architecture… but what about a strict many_many relation? Are you considering versioning for these as well?

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Sam Minnée]

No, the plan is that if you have data that is currently stored as a strict many-many, you will need to convert it to a many-many-through structure.

--

Sam Minnée

CEO

SilverStripe Limited

[Roman]

I see. Wouldn't that lead to several unnecessary DataObjects that are just being used as intermediate objects? Seems pretty unintuitive to set up a plain many_many relation…

Have you considered something like different join tables for the different stages? Eg. if you have "Page - many_many - Images", you would get "Page_Images", "Page_Images_Live" and "Page_Images_versions" join tables?

I guess the drawback of this is, that it's introducing a special case to version many_many relations… and your approach uses already existing tools.

But my most common use case for many_many are File relations by a large margin. So I would end up in doing something like this?

Page - has-many - PageImageHolderObject
Image - has-many - PageImageHolderObject
Page - many-many - Images through PageImageHolderObject

Or did I misunderstand the many-many-through architecture? Could you make an example how to set up a Page - many-many - Files relation with many-many-through?

Thanks - Roman

[Sam Minnée]

Over the years we've hit a lot of limitations with many-many relations and in general we want to put our efforts into get the many-many-through feature working well.

Once it's in place there's a possibility that we could refactor the implicit many-many feature to work by generating an inferred DataObject. But that's for the future.

Your assessment of the set-up is more or less correct, although I think it would be sufficient only to define the pair of has_one relations on the PageImage data object - the has-many relations would only be necessary if you wanted a way of accessing the PageImage objects themselves.