Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Ensure that duplications fail over to owned objects #106

Merged
merged 1 commit into from
Feb 5, 2018

Conversation

tractorcow
Copy link
Contributor

Parent story #28

Ensures that, in the absence of cascade_duplications() versioned will use owns to infer duplications.

$allowed = array_merge(
array_keys($this->owner->manyMany()), // Require mapping table duplications
array_keys($this->owner->belongsTo()), // Exclusive record must be duplicated
array_keys($this->owner->hasMany()) // Exclusive records should be duplicated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure the has_manys should be duplicated. it's a relationship to an external record.

It's difficult because there's no one-size-fits-all approach here. Sometimes the has_many should be duplicated and other times it shouldn't and it really depends on the case...

With WidgetAreas for example, we leave it to the WidgetArea to duplicate the linked Widgets because in that instance it's what's needed (partly out of necessity because there's no interface for detaching a widget from one WidgetArea so changes and deletions propagate unexpectedly when using the interface.

But for ContentBlocks where they should be shared among pages, this behaviour is going to be undesired.

I think out of the box, we shouldn't be duplicating has_many relations...

Copy link
Contributor Author

@tractorcow tractorcow Feb 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's owned (and thus necessary) and a has_many, then it's necessary to duplicate it.

You can work-around this by declaring a cascade_duplicates for that object, and then owns will no longer be used as the default. That's what we would do for widgets.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But for ContentBlocks where they should be shared among pages, this behaviour is going to be undesired.

ContentBlocks don't own pages so it won't be a problem there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI at this stage we don't support many_many for content blocks

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is many_many on the roadmap?
It always made sense to me to keep it unsupported for Elemental

Copy link
Contributor

@robbieaverill robbieaverill Feb 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support for it is in dnadesign/silverstripe-elemental-virtual (not SS Ltd supported) at the moment, but I don't know about commercial support for it longer term =)

@flamerohr flamerohr merged commit 6b6a8ff into silverstripe:1 Feb 5, 2018
@flamerohr flamerohr deleted the pulls/1/duplicates-is-easy branch February 5, 2018 01:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants