Is there a feature request for a duplicate function that also duplicates inner collections, references and files? If not… please can you add one for me? It would be really useful. Thanks
How do you imagine it would work if there is a multi-level hierarchy of databases?
e.g.
A → B
B → C
B → D
Does duplicating an A create duplicates of all Bs linked to it, and does this result in duplicating of all Cs and Ds linked to these Bs?
What do you mean by duplicating references?
I’m not sure that this is sensible. It would grow the storage space required unnecessarily.
Instead, might it be better if Fibery supported a basic file storage system so that a file could be linked to from multiple places…?
For us, most relationships are many-many.
A duplicate of A would not create duplicates of entities in B, rather it would just inherit the relationships to the existing entities in B.
I fully understand this is a complex problem and there may not be a one-size-fits-all solution.
What do I mean by ‘References’? I don’t know. I was stealing from Michael. I thought he might know what he was talking about. Forgive me if I’m mistaken! 
As for files, you are quite right: It would be much better to have a file storage system whereby files can be linked to multiple places 
Haha! In this context, I think he means to-one relation fields, which actually do get copied.
But copying many-to-many relations (i.e. linking to existing items) doesn’t bring with it many headaches, so I guess this should be a feature request.
UPDATE: I’ve split these messages out into a new topic
The file store topic is probably a bigger can of worms though 
1 Like
Intelligent handling of collections when duplicating entities is a very sensible and popular request. But different types of M2M relations need to be handled differently, according what they are actually modeling.
The problem is that each relation must be handled in accord with its “purpose” or abstract role, which Fibery doesn’t know anything about (although it could).
I.e., when duplicating an entity, some of its collections just need to be copied (keep the existing entity references), while other collections need the entities cloned/duplicated and linked appropriately.
The difficult part is to define how each relation should be handled – copy, clone, or ignore? – and this must be done recursively for every DB related to the “root” entity being duplicated.
I actually wrote a script to do this, but I never finished it because of how frustrating the debugging experience was, plus some vexing limitations of the older version of Node in use – e.g. no support for Promise.allSettled() – which contributed to the debugging difficulty. If Fibery updates their Node version perhaps I will continue that project. 
Different types of M2M relations, and how they should handled:
(1) Multi-select / “tags” collection
One side of this relation is a DB of “tags” (or multi-select options), and the other side is any other DB where each entity has its own unique set of tags/options.
For relations of this type, the “main” entity’s references to Tags are simply replicated (not cloned).
(2) Hierarchical “parent-child” tree structure
A self-relation implementing a strict tree structure; e.g. tasks with sub-tasks, pages with sub-pages, etc.
This case is also easy, if the intent is to duplicate/recreate an existing strict tree structure from a certain node on down. Depth-first cloning of the tree, replacing the parent & child references with their clones.
(3) Graph
A self-relation implementing a graph structure.
More complicated than a tree, but still amenable to duplication of the entire graph. Traverse the graph, cloning each entity as you go, then re-traverse, replacing the original entity references with their respective clones.
(4) Other
Any M2M relation that isn’t well-defined is not suited to automated cloning/duplication. But the above is not an exhaustive list – there are probably additional relation types/use-cases that would be amenable.
The real point here is that if we can define a particular M2M relation’s purpose (and have its limitations enforced by Fibery, e.g. a strict tree-structure), then it becomes a reasonable subject for automated duplication.
Fibery could offer some new relation types like “Tree”, “Tags”, “Graph”, etc. (which would just be restricted M2M types under the hood). We already have a version of “Tags” in the Multi-Select list, but its limitations are too restrictive for many uses – e.g. they are limited to a single DB.
3 Likes
Although this is a very intelligent approach, I fear that more ‘casual’ users will be put off by Fibery trying to teach them the necessary concepts around relation types 
1 Like
LOL yeah I suppose it could become a problem when Fibery needs to explain WHY some entity can’t just be automatically cloned/duplicated, the way the user expects it “should” be… “but it seems simple enough to me!”
1 Like
I don’t think Fibery should focus on casual users. Fibery should be as powerful as it could be, because people who are NOT casual users will set up workspaces for their own or other companies or create templates that are usable for casual users.
SAP is neither easy to setup, nor easy to learn/use. Most users don’t even remotely use all functionalities, they just learn whatever they have to to do their work.
2 Likes
Hi! Is there any update on this request?
Nothing to report. It’s not planned in the near future.