Deep Copy (intra-space)

Ideas & Features
1

I just posted a prototype deep copy in Share Your Space that might be useful if fully productized. It’s currently hardwired to a nested 1:M project-section-task schema, but it will deep copy all levels of the schema, as well sub-projects, sections, and tasks.

So, my suggestion would be (if it’s possible) to extend this prototype (or sth like it) to support:

  • M:M relationships
  • automatic identification of field types, names etc.

I suspect this would cedrtainly have to have limits, but even the very basic prototype I wrote is useful for templating projects within a space.

An alternative might be a customizable skeleton function, which folks could modify for any use case.

2

Quick question: imagine I have a space with dbs called Meeting and Topic, which are related m:m

In other words, a Topic may be discussed at many meetings and a Meeting may discuss many Topics:

Meeting A ↔ Topic 1, Topic 2, Topic 3
Meeting B ↔ Topic 2, Topic 4

If I ‘deep clone’ Meeting A, what would you expect the result to be

Meeting C ↔ Topic 1, Topic 2, Topic 3
or
Meeting C ↔ Topic 5, Topic 6, Topic 7

Now what if it was Projects and Sprints? What if it was OKRs and Workstreams? …

3

Hey @Chr1sG

I think there are 2 potential scenarios, and each has valid use cases.

Scenario 1 - each project (and its children) are standalone and unrelated to other entities in the same space, including their respective children and grandchildren. The underlying assumption in most of my use cases is that, within the same space, each top-level entity (e.g. Meeting) is copied for the sole purpose of grouping similar projects in the same space.

So the result wouold be: Meeting C ↔ Topic 5, Topic 6, Topic 7

Pros

  • relatively easy to implement

Cons

  • lower level M:M entities cannot be shared across meetings, Projects, etc.

Scenario 2 - children and grandchildren (e.g. Topics and Meeting Rooms) are in shared across top-level entities (e.g. Meetings). Most enterprise-level use cases would be biased toward this scenario.

And clearly, in this scenario, the result would be: Meeting C ↔ Topic 1, Topic 2, Topic 3

Pros

  • supports coplex use cases

Cons

  • possible unintended consequences

Pre-coffee Random Thoughts
I’m fairly confident that, within a space, the scenarios above are fixed - that is, when copying a Meeting-Topic relationship, a new Topic will always be created, or not. But it would be consistent within a space.

Maybe I’m over-engineering a possible solution, but why not define a parameter in the Advanced section of Relationships - call it Deep Copy Inheritance Bias.

And for each M:M relationship, the schema designer could set the Inheritance Bias for alll entities in the same space. A deep copy function would interpret the Inheritance Bias to produce the results in the two scenarios above. You could even mix and match, such that, within a space, some M;M relationships would support creating new entities and others would not.

I think this is consistent with the approach Fibery uses for other Relationship properties.

Pros (again, pre-coffee)

  • I think this approach would cover most use cases.

Cons

  • once set, the Inheritiance Bias would probably have to be read-only. But again, Fibery has this constraint when converting a 1:M relationship to M:M.

I imagine this will not pop to the top of your backlog anytime soon, so I may try modifying my deep copy. In lieu of a scema Inheritance Bias, I can easily just add a constant in the init section.

I hope this addresses your questions.

Cheers

4

A general purpose cloning/deep-copy solution certainly needs a way to determine how to treat each relation “appropriately” (i.e., whether to clone the related entity, or just link the existing one).

5

@Matt_Blais I know this is sth you’ve thought about and worked on, so … another dimension to this problem is cycling thru each property/field in a database to determine how to copy it - boolean, single-select, rich text fields all have unique requirements. Have done anything with “auto-recognition” of each field name and type - I’m trying to figure out how to get around hard-coding both the field names and the methods to copy them…

6

See @Polina_Zenevich’s post here, for how to handle all the field types while cloning:

7

Hey @Matt_Blais ! Thx so much for posting this! This answers a lot of questions about cycling thru the schema w/o hardcoding my script. I’ll add to the next version of my deep copy script.

Tweaking Fibery is becoming a FT hobby…