Allow resource relations to be maintained or duplicated

[ns139426]

For duplicating resources with ownership relations, I found it useful to be able to attach the previous relations to the new model. This could be achieved by overloading the replicate() method on the model but this seemed like a more elegant solution.

For my purposes I'd used relationsDuplicate and relationsMaintain for clarity in the options but kept breaking changes out of this PR.

[jackabox]

Thanks for the contribution - a couple of questions:

Does this work for belongsToMany as well?

What's the intended difference between "maintains" and "relations"?

[ns139426]

It works for the belongToMany relationship that I use but my testing probably can't be described as extensive at this point.

As mentioned, the wording is not ideal for the option but I was conscious of avoiding a breaking change. The intention for maintains was to persist/maintain an existing relationship rather than duplicating the records. If many teams owned a quiz and the quiz had many questions, the ideal operation for replication would likely be to maintain the existing ownership relationship so the teams retain access to the correct quizzes but that the questions are duplicated so that they can be modified separately.

[jackabox]

I'll need to spin this up and test it quickly.

I believe we need another term other than 'Maintain'. For example 'Preserve Relationships'. preserveRelationships I'd prefer it to be obvious where possible.

[ns139426]

Absolutely, if a breaking change was acceptable I’d suggest preserveRelationships and duplicateRelationships as clear and obvious names. It would be trivial to add support for duplicateRelationships and maintain the existing relationship option but the code obviously gets a little muddier.

[jackabox]

Going to try to get this into a v1 release to allocate for the breaking change. Haven't forgot just not got around yet.

[jackabox]

Might be worth integrating this into #20 and using one solid logic (with backward compatibility for the different relation types)

[ns139426]

Might be worth integrating this into #20 and using one solid logic (with backward compatibility for the different relation types)

Definitely. I can wait until the requested abstraction work is done there and then look to add these changes in a sensible way.