Copying fields between databases

Get Help
1

Hi, I’m pretty new to Fibery.

I want to create an entity “subtype” of an existing database. I can either:

  1. update the original database by adding new fields that are specific to the subtype, and a field that will label new entities with the name of the subtype. This reduces redundancy but makes my master database more complex

or

  1. create an entirely new database specifically for new entities of this subtype. Adds some redundancy because some fields will be the same in both databases, but each database only needs a subset of fields so each database is cleaner and less complex.

I currently favor option 2, so I can keep my databases relatively clean and easier to manage when I’m administering. There should be a few fields that are copied over from the original database to the new database. Is there a way to do this, or do I need to re-create all new fields manually?

And if you strongly favor option 1 (I assume you’d say I can have arbitrarily large numbers of fields and rely on views to filter down on the relvant information), I’m open to that.

Hope my question is clear. Thanks.

2

I was hoping someone would offer a quick reply or tell me where to search for the relevant info. Though I can appreciate the high-level discussions among the experienced/power users on here, is anybody from Fibery monitoring the help channel for more basic questions from new users? I’ve attended the weekly webinar, which was like, “sit down and open your mouths so I can connect this firehose” so I figured I’d try this alternative channel. 0/2 so far.

3

Hi!
Regarding the example above, I can’t suggest a good solution :slight_smile:
As for me, everything is based on the use case, that you have. What is “subtype”? What kind of data are we talking about?What kind of fields are we discussing?

From a technical perspective, both suggested solutions are “correct” (if I may say so). But to understand which one is better, we need to know not only tech part but the context as well.

As for the reply time - indeed, we check the community, but less frequently than Intercom chats.
Community is for discussion, where everyone can participate, not only the Fibery team. And Intercom chats are better for fast replies and solutions, tied to your case.
Maybe that’s not obvious indeed, and sorry for the waiting and confusion :pray:

1 Like
4

I understand you want help with a one -time conversion of labeled entities into new database entities?

After creating the fields you need in the new database, you can use a grid view that lists the old database entities, filter that to show only the labeled entities, select all of them and use the Actions dropdown in the grid view to convert to the new database type. After that, delete the old database entities with labels. Note: relations will not be converted. Test first with test databases if this works.

5

Thanks for responding, both. I’m trying deliberately not to specify a particular use case, because I’m searching for a general principle or convention. If you have two similar-ish types of entities (for example, “customers” and “investors” are both subtypes of “people”), should they be in one larger database (called “people”) designed to capture both customers and investors and all other categories of people, or create a different database for each type of person? Let’s say that all types of people have 4-5 fields in common (examples: name, phone number, email, linkedin URL, etc) and 4-5 types of fields that are unique to that type of person. If I have one master database for all types of people, then the number of fields grows with the number of types of people. Once there are 10 types of people, there’s 50+ fields, and the database has grown quite complex (and it will also be somewhat sparse). It will be painful to administer this database, but maybe that’s OK because maybe then you only need to configure a different grid or table view for each type that shows only the 5-10 relevant fields one time for each type.

At first, I found that too complex and unwieldy so I was creating multiple databases for different types of people, and I was replicating some fields, and found that to be painful.

Is there any way to copy a field from one database to a different database? For example, if I have a multi-select field called “category” and there are 10 different choices, it is painful to manually recreate the same field in a new database, and it would be much easier to have a way to copy the field including its choices from one database into a second database. For example, I have one mater database for “people” and another master database for “entities” (which are groups of people), and both people and entities can be assigned to common categories. Ideally, the “category” field is in sync between the two tables. So maybe I create a separate database called categories and use a relation instead of a multi-select? It seems like overkill because I “categories” doesn’t need to be its own database.

Furthermore, I tried exporting/backing up my data and it didn’t save any relations! I can’t afford to lose this type information when I backup my data. Is there any way for the data export to include the relations?! As the introductory video explains, relations are the “glue” of Fibery, so I hope you don’t lose them when you export your data, otherwise it’s not a good enough backup to me and I feel vulnerable that if something happens to Fibery, I will lose all of the contextual information that I depend on.

Also, can you copy an entire database from one space to another? I only see a way to convert a single entity into a new entity in a different database, but not a way to copy an entire database. This is also painful because only data for which the fields are identical between the two databases is retained! It just throws away data if it doesn’t find a match in the fields. which means I need to manually make sure that there are fields that match exactly.

What’s Intercom and where can I find it? I don’t see it mentioned anywhere at fibery.io.

Thanks, hopefully my questions will help someone else.

6

Unfortunately not. And the entire “complexifying” issue you’re talking about here is definitely a big concern for me and some other folks here as well.

Yes, exactly, this is unfortunately the best way to do this for now: you create a new Database for every “relation” that you want to be shared among multiple Databases. It is quite a “heavy” solution. And it’s unfortunate because behind the scenes even the multi-selects are a form of “database”, it seems (try alt-clicking on a single or multi-select option). So why can’t they be shared between Databases? I’m not sure. I imagine there is a good reason, but I haven’t seen it well articulated by the support team as-yet. Just knowing how thoughtful and intentional they are with everything I imagine if it were technically feasible to do this, it would have been done by now or at least been discussed as a future plan, so again there must be a good reason I’m not aware of.

No, but you can move a database from one Space to another. The workaround to “Copy” is to create a Template from a Database/Space and then re-add/import it to your workspace. :grin:

7

Thanks, Oshyan. I didn’t know I could save a custom template. Is this the thread you’re referring to, with a kind of workaround to accomplish that?

It occurs to me that the “heavy” solution to keep certain fields in sync across different spaces and databases by making them into their own databases might be accomplished if Fibery implemented categorized “tags” that we could set globally?

One major concern of mine is that the more I rely on relations between different databases (really a powerful concept! The “glue” of Fibery! The reason I’m using it!) the more I am concerned that when I Export Workspace (this is the appropriate way to backup my data?) the csv files that are created exclude all of the relations. I am struggling to understand that policy. When I construct a table using relations, the relations are not merely extra; they are an important part of the information. If they are lost when I export, then it’s a very incomplete export. Are folks ok with that? I can’t imagine I’ll become comfortable entrusting my super important-to-me data to a third party (Fibery, Notion, whoever) if I can’t back it up regularly in a way that I could rebuild it if needed. Thoughts?

1 Like
8

Also, exporting the data doesn’t include the views? It is time-consuming to configure these. No way to back them up?

9

This isn’t correct. The CSV export includes unique ids for each entity, and where one entity is linked to another, this is shown by including the id under that relation column.

1 Like
10

It is actually now possible to ‘share’ a select field between databases. If you open one of the select options (using alt-click) you can add a new relation field to a secondary (or tertiary, or quaternary, …) database.
The cardinality of the added relation determines whether it behaves like a single- or multi-select.

2 Likes
11

I do now see that the relation fields are included in the backup! The fields in the csv export are in a different order than the fields in the original, and it hadn’t occurred to me to search out of order (I’m a little curious why, but no bother). That said, the entries from linked entities are listed by name, not their unique id’s as you wrote (or let me know if I misunderstood?). The csv I am looking at is good enough for me for now. It is interesting though that the markdown backups of rich text uses a different convention. In the places where I created a new entity from a string of text within the rich text field, the backup looks like this [[workspace name / database name: entity name]] which seems like a good solution. If it were me, I would use a similar convention in the header of the csv output. The header entry for a linked entity field could be [[workspace name / database name]]. Let me know if I’m not thinking about this right.

12

Not sure I follow. What do you mean by “open one of the select options”? Alternatively, is this documented somewhere?

13

Thanks for the reply, Yuri_BC. I didn’t quite understand your question. What’s a labeled entity vs a database entry? Also, I don’t see any way to select entities in grid view. Table view allows entity selection, though–is that what you were thinking?

I’m thinking about using multiple databases with some fields in common vs. one database with a large number of fields, only some of which are needed for each entity. And for the former solution (multiple databases with some fields in common), wondering the best way to duplicate fields other than making the field itself its own database.

14

Rich text is exported as markdown, but there is no universal standard for how to represent links in markdown, so in Fibery, we use [[Space name / entity name]]

The #mentions in rich text are not the same as structured relations (which are either to-one or to-many relations) and for which there is no reason to prefix the entity identifier with the space name, since the relationship will by definition only be able to link to a single database.

Given that there can be more than one field that relates database A to database B, it does not make sense to specify the relation using the destination database name, but rather we use the field name to distinguish them (since no two fields can have the same name in a given db).

I was referring to the case where a to-one relation is present - there should be columns in the CSV export for both the ID and Name of the linked entity.
I’ll need to check why we don’t do the same for to-many relations.

15

https://the.fibery.io/@public/User_Guide/Guide/Select-Field-(Including-Workflow)-87

Use alt-click to open an option (where you can then add fields etc.

16

You can just click on a row and then shift-click or ctrl-click to add more rows to the selection.
(similar to a lot of table editing tools)