Glossary, ACs, desynchronize and sync every tables #1
Conversation
fflorent
changed the title
issue-416/README.md
Outdated
| - AC2.1 - MH: The user sees what data have been changed through a diff | ||
| - AC2.2 - SH: The user also sees what columns are removed or added | ||
| - AC3 - MH: A user can convert an existing table to a synchronized one | ||
| - AC3.1 - MH: If another table references a column of the table to synchronize, the reference is not broken if the external table has a column of the same id |
There was a problem hiding this comment.
I understand that I could be really good to have this feature, but it could be hard to develop. For you, not having this feature at first would be a nonsense?
There was a problem hiding this comment.
I may be wrong, but I think it can be quite simple to implement.
Technically, I would see these steps to avoid breaking the references:
- merge the target columns with the source columns;
- inject the data
We already can get the column definition through the API and create new columns with the same definition, which is quite convenient:
- https://support.getgrist.com/api/#tag/columns/operation/listColumns
- https://support.getgrist.com/api/#tag/columns/operation/addColumns
We just lack of a PUT method implementation as it exists for records to add the missing columns or replace the existing ones if necessary.
I have started implementing a POC using the API to see how the feature would look like and have a concrete material to discuss on for what we should do.
Edit: by column definition, I mean the fields definition you can see in the API:
| - AC3.4 - SH: The user also sees what columns are removed or added | ||
| - AC4 - SH: The user should be able to unlink a synchronized table which would become a simple table; | ||
| - AC5 - NTH: A "synchronize every tables" button is offered to the user in the "raw data tables" view; | ||
| - AC6 - SH: Edits to synchronized tables should be forbidden; |
There was a problem hiding this comment.
To be seen after the POC. If the POC says that references can be synchronized, we can keep this AC.
If not, things get more complicated, because the user would want to manually copy/paste the result of a formula from the external table to the synchronized one.
There was a problem hiding this comment.
The references cannot yet be retrieved. The main problem here is that when using add-or-update on records, the IDs of the added or updated records are not returned (mapped to each submitted elements)
fflorent
force-pushed
the
dev/issue-416/ac-and-import-into-an-existing-table
branch
from
eff0054
to
8ef8986
Compare
| - AC1 - MH: A user can create a fresh table synchronized with an external document | ||
| - AC2 - MH: The synchronization is made when the user requests it. | ||
| - AC2.1 - MH: The columns of the synchronized table are updated/created/deleted so it reflects what exist in the external table | ||
| - AC2.2 - MH: Idem for the records |
There was a problem hiding this comment.
NB: record can be here seen as synonym for row
fflorent
force-pushed
the
dev/issue-416/ac-and-import-into-an-existing-table
branch
from
f831103
to
df80cec
Compare
Proposals for issue gristlabs/grist-core#416
Introduced:
Must Have(MH) >Should Have(SH) >Nice to Have(NTH);To preview the whole document more conveniently, I suggest to use this option:
