I organized my tables into documents, not realizing that Reference columns can’t work across documents and that I would later need to reference a table in one document from a table in the other document.
What are my options for getting a table into another document fully intact?
You can download your table from one Grist document then import it into another. Note that when you import the table, it will import the headers and the data but you will need to reset the column types and add in any formula columns.
To download your existing table, I’d recommend navigating to Raw Data and downloading from there. This way, you can ensure you are downloading the full table (including any columns that may be hidden in views). From Raw Data, click on the data table to open the view then click the three-dot icon at the upper right of the table. Select one of the download options.
Select your file to import then import it into a new table.
You will need to set up column types again but it should be fairly quick to do. For example, in the screenshot below, ‘Room’ and ‘Category’ were choice columns. The values imported as text. When I change the column type to Choice, the Choice options populate based on the values imported. If you had colors assigned to choices in your other Grist document, you can copy/paste those Choice values (with formatting).
That’s not good enough (in my question I wrote “fully intact”), I need to be know that I’m preserving the column types and all other metadata (e.g. formulas, trigger formulas, and anything else).
Maybe there’s a straightforward way using the rest API? Or maybe I could download the documents as SQLite files, combine them with some SQL or something, and then upload? Or anything?
I’d rather do a little more work and know that everything is preserved than rely on myself to check everything and copy paste various little things.
It is possible to GET all the columns of a table from one document, and POST them to a table in another document with the REST API. However, some of the fields of the metadata hold values which are numeric identifiers for other columns/fields in the same document, and these are not guaranteed to be the same across documents. Basic things like column alignment settings, labels, formula code, etc. should be able to be copied over without a problem, but things like trigger formula dependencies, row/column conditional styles, and reference column configuration will be problematic because their configuration depends on such numeric references. Editing the SQLite file directly has the same problem.
In the schema for the body of a POST /columns (linked below), the main ones to watch out for would be widgetOptions (some of the options store numeric references), visibleCol, and recalcDeps.
Can you please give me more concrete instructions.
Which endpoints do I need to call to get all the data and metadata?
Which endpoints do I call to recreate them?
Can I send the data from the first endpoints verbatim to those in the second category, or will I have to pull it apart and reassemble it? If so in what way?
For each table you want to copy over, the general steps should be:
Get all the columns of the source table with the GET /columns endpoint.
In the response, remove the following from each column’s fields property: colRef, parentId, parentPos, summarySourceCol, displayCol, visibleCol, rules, recalcDeps. Also remove the following from widgetOptions, if present in the JSON string: rulesOptions.
Send the modified response to the POST /columns endpoint.
Get all the records of the source table with the GET /records endpoint.
Remove the id field from each record in the response.
Send the modified response to the POST /records endpoint.
Grist is great in general in terms of UX but there is a real gap there in the product : being limited to excel to transport a table from a document to another document is very limiting: from what I understand it cause you to loose layouts, column definitions, link between tables, etc… As grist invites you to have your own workspace, and to work on your own copy … but if there is no way to easily merge back the changes it is a bit like an unfinished journey there. Is there is a trick for this / if there is any progress on this, I think will be much appreciated. Obviously, the API can help, but it is not exactly good UX for something that is quite common in terms of workflow.
Hello, I agree, there should be a way to export as JSON or YAML or XML as Excel/CSV won’t preserve formulas and all the nice things that grist provides.
The tutorials make it seem like you can move a raw data table from your personal to team page without a problem. There’s no warning that if you spend hours building and filling out a raw data table, you can’t move it to be next to a raw data table in a different “document.” This newbie thought I was building spreadsheets that I could link together later. There’s no warning that they’re stuck separate from each other unless you’re an “API/SQL/schema/visibleCal/endpoint” (don’t even know what those words mean) person (WAY above my pay grade!) Would LOVE an easy way to do this. Feel like a clearer description of hierarchy would be helpful so the mistake wasn’t made in the first place. Thank you for the info given and this forum.
Sadly this is one of the many things that hold me back from recommending Grist. A great product with promising features yet still lacking so many basics like this. I can duplicate raw data which includes all of the column settings, yet I cannot move this to another workspace… seems a strange omission.
wouldn´t it be possible to DOWNLOAD THE WHOLE DOCUMENT, which is actually like a XML and then edit it and remove what you don´t want leaving only the table you need?
edit: I guess it would be possible to edit, (although it seems its an SQLite document, not a XML?) but wouldn´t make a difference, because documents can only be imported as brand new, you can´t import part of a document to another existing document, you can only importa tables, without rules, formating, etc