Convert & Delete/Replace Entity preserving references

[cannibalflea]

Entity conversion from one type to another is already implemented and works really well. The default behaviour is to create a new entity of the new type and copy content fields of the same name and type from the existing entity to the new entity.

However, one of the things that does not transfer over are references/back-links. This makes sense when you are copying/duplicating an entity, but in some cases, the intent is to actually convert an entity from one type to another and replace/delete the old one (i.e. a true conversion rather than creating new and copy content). In this case the desired behaviour is to have all the back-links pointing to the new entity.

This is not a big deal if you have a few entities and only a few backlinks. But it can quickly become a nightmare if you are converting large sets of data. So I am proposing extending the convert function to provide this possibility.

I think this was discussed as part of the [APPROVED] Replace All References, but that request seemed to focus on general ability replace all references to a certain entity with a new reference (see also Search & Replace). If they are one and the same, I will combine and delete this.

[Polina_Zenevich]

Hi!
That’s the real problem, we face as well
Noted your feedback, have the feature-solution in our backlog
Will be back, once it’s done

Btw, if anyone else is struggling here too - please, leave your comments here, so we could better understand how the popular (painful) the problem is

[Mikkling]

I tend to do a lot of converting-to-type-then-deleting as i test, tweak, and scrap Spaces and Entities all the time, and it would be nice if references could be transferred.

[Yuri_BC]

We need to convert the same entity to a different entity type a lot, and never actually need to copying into another entity type that now happens.
I assume the copying of content into a new entity of another type, as happens now, may be a security measure to prevent loss of data or relations, but I did not use that feature once.
Essentially, the need is to clone one entity into another database, include all relations and all references as much as possilbe as far as fields are corresponding, and delete or archive the old entity.

It will likely need a step in between in which users can match fields so that relations and references are not lost if the databased don’t contain the same type of fields.

[B_Sp]

I would like to add a hearty vote for this feature as well. I also took the liberty to edit the title of this with the addition of “preserve references” hopefully that is OK @cannibalflea

My team has been in Fibery a while, since late 2019, and we have a lot of db hierarchy structures that are evolving, and could use some edit. This could be solved by Polymorphic Relations but I know that is some time away. We track a lot of static things, like products, service providers, equipment, etc. and some of the structures of these things need edit after 4 + years - we need another level in our hierarchy for equipment, a sub-product is now a product, or vice versa, etc. This ideally would lead to moving these older entities, with tons of references and history, into new structures. In more free-form tools like Notion or Tana I can just move those out and basically “retag” them into new DB’s with no issue. The entity stays the same and I don’t need to “convert” it to a new Type. There might be some issues with field mapping but there are simple ways those tools solve that.

However right now in Fibery the conversion feature only maintains comments as far as I can tell. very importantly all references will be lost. This means we are sitting with a lot of key entities that are core to our business - like products, etc., that are stuck in the wrong structure and we can’t move them at the risk of losing years of history.

I also wanted to repost here some other suggestions I had for more involved process in converting entities. Again I think with the degree of inflexibility within Fibery because entities are stuck in DB’s, which I would call the more “atomic” level in Fibery, vs. say another tool like Notion where the entity is the more atomic level, and DB’s are formed more loosely to essentially group entities, but the entity (or page, issue, node etc. - however the other apps refer to them) are the core base-level piece of data.

@B_Sp

I agree with this and you are talking about some more advanced ways to relate two Entities that I would really advocate for. There are numerous discussions in the community around aspects of this, sorry I don’t have time to find the references, but off the top of my head:

• Converting an Entity into an Entity within another Type, with full mapping options, and other options like “maintain references” and “copy comments” and other advanced copying
• Linking An entity to a newly created entity that would copy over much of the original entity’s data, but be in another Type
• Your request to merge two related entities into one
• Full tracking of the history trail of the connection being made between the two Entities: in the new one, info that it originated with the previous one; auto-write to comments about the “conversion” from the originating entity, etc.

I would have great use of this, and I advocate for dev time to be spend to build out sophisticated capability within Fibery to move Entities in various ways between Types, and to merge them if need be. I think this is going to be essential down the road due to the flexibility of Fibery and constant need to tweak set-ups and teams’ needs evolve.

Thanks!

[Chr1sG]

Just adding a link here for anyone who didn’t find this related topic:

Cloning an entity and re-mapping where it is mentioned

Sometimes, you might want to convert an entity of one type into an entity of another type. Fibery does have native support for such a conversion [image] but any other entities in your workspace that mention the original item, will continue to point to the original and not the new clone. To solve this, I have created a script which will re-map all the #mentions in entities so that they point to the newly created one. The script is designed to work as the second action in an automation, where…

[B_Sp]

Yes I’ve seen that. I am hoping we can get this natively, it’s a lot of work for a non-coder to try to apply your solution.

I guess you could even talk about this functionality as simply “moving” an entity from one db to another. It’s a common feature of a lot of similar tools like Fibery. The entirety of the entity would be preserved, it would just move into the new DB with the requisite mapping as well.

Either way, I am really hoping we can simply get this feature soon, would really help with dealing with structures that initially seemed correct, but now need adjusting.

[Wilco_Boode]

Im running into a similar issue.

It would be great if the convertor can automatically detect same-database relationships in the old and new database, and re-link / transfer entity relationships that way.

[Chr1sG]

@Wilco_Boode

It would be great if the convertor can automatically detect same-database relationships in the old and new database, and re-link / transfer entity relationships that way.

Are you talking about relations or references (which I think is the original topic of this thread)

[Wilco_Boode]

Ah, I was talking about relations

[Chr1sG]

For relations to the same type, with the same name and cardinality, the links should be maintained during conversion.

[Wilco_Boode]

Then that might be a bug (or different from how I used it)

So i had 2 databases

Database 1 Variables:

1. Name (text)
2. Content (text)
3. Parent (one / DB 1)
4. Children (many / DB 1)
5. var_x
6. var_y

Database 2 Variables:

1. Name (text)
2. Content (text)
3. Parent (one / DB 2 )
4. Children (many / DB 2 )
5. var_a
6. var_b
7. var_c
8. var_d

When I pressed convert from DB1 to DB2 the content and name were ok, but the parent and children were not set. I would have expected these to remain, but in the new structure

[Chr1sG]

Imagine you have the following items in Database 1:

- Entity 1
-- Entity 1.1
-- Entity 1.2
--- Entity 1.2.1
--- Entity 1.2.2

If I choose to ‘convert’ Entity 1.2 from db 1 to db 2 are you expecting that it will automatically also convert Entity 1, Entity 1.2.1 and Entity 1.2.2 as well?
What about Entity 1.1 ?

It is unlikely that the simple ‘convert’ function (which basically operates on a single entity) will ever cover a complex case with self-relations.

I think what you might be looking for is something like a cross-database ‘deep copy’, followed by deletion of the original tree.

[Chr1sG]

I’ve updated my earlier post for clarity:

@Chr1sG

For relations to the same type, with the same name and cardinality, the links should be maintained during conversion.

In your example, the field called Parent is a relation to DB1 in the source db, and a relation to DB2 in the destination db, so convert will ignore it.

[Wilco_Boode]

I encountered this when I choose to mass-convert a whole group of items from DB1 to DB2. I did not expect it to auto-convert connected once that I did not select (that sounds like a massive rabbit hole)

Since the structure is the same in both databases, I expected it to also maintain the relations as those are already defined.

I see the issue with my assumption, and now understand that it did not belong in this thread, the deep-copy is closer to what I intended, but I get the issues now that I read the conversation over there.