6 Commits (ec20e7fb68786e10979f238c16c432c50a9a7464)

Author	SHA1	Message	Date
Arnaud Peich	c9933b6908	Use relative imports only in plugin folder (#328)	2 years ago
Alex Hall	62792329c3	(core) DocApi meta endpoints: GET /tables and POST/PATCH /tables and /columns ... Summary: Adds new API endpoints to list tables in a document and create or modify tables and columns. The request and response formats are designed to mirror the style of the existing `GET /columns` and `GET/POST/PATCH /records` endpoints. Discussion: https://grist.slack.com/archives/C0234CPPXPA/p1665139807125649?thread_ts=1628957179.010500&cid=C0234CPPXPA Test Plan: DocApi test Reviewers: jarek Reviewed By: jarek Subscribers: paulfitz Differential Revision: https://phab.getgrist.com/D3667	2 years ago
Alex Hall	1864b7ba5d	(core) Add BulkAddOrUpdateRecord action for efficiency ... Summary: This diff adds a new `BulkAddOrUpdateRecord` user action which is what is sounds like: - A bulk version of the existing `AddOrUpdateRecord` action. - Much more efficient for operating on many records than applying many individual actions. - Column values are specified as maps from `colId` to arrays of values as usual. - Produces bulk versions of `AddRecord` and `UpdateRecord` actions instead of many individual actions. Examples of users wanting to use something like `AddOrUpdateRecord` with large numbers of records: - https://grist.slack.com/archives/C0234CPPXPA/p1651789710290879 - https://grist.slack.com/archives/C0234CPPXPA/p1660743493480119 - https://grist.slack.com/archives/C0234CPPXPA/p1660333148491559 - https://grist.slack.com/archives/C0234CPPXPA/p1663069291726159 I tested what made many `AddOrUpdateRecord` actions slow in the first place. It was almost entirely due to producing many individual `AddRecord` user actions. About half of that time was for processing the resulting `AddRecord` doc actions. Lookups and updates were not a problem. With these changes, the slowness is gone. The Python user action implementation is more complex but there are no surprises. The JS API now groups `records` based on the keys of `require` and `fields` so that `BulkAddOrUpdateRecord` can be applied to each group. Test Plan: Update and extend Python and DocApi tests. Reviewers: jarek, paulfitz Reviewed By: jarek, paulfitz Subscribers: jarek Differential Revision: https://phab.getgrist.com/D3642	2 years ago
Jarosław Sadziński	db57815d2b	(core) Improving custom widget API. Changing destroy function signature. ... Summary: Destroy function in TableOperations was throwing error when invoked with a single record id instead of an array. Now it returns a void type. Also changing mapColumns function signature as it doesn't require options for a default behavior. Test Plan: Updated tests. Reviewers: alexmojaki Reviewed By: alexmojaki Differential Revision: https://phab.getgrist.com/D3404	2 years ago
Paul Fitzpatrick	a5f5ecce19	(core) add grist.getTable(tableId) and a getTableId() method in plugin api ... Summary: Makes the new TableOperations API available for all tables in the document. Adds methods for discovering the tableId of the selected table. I was very tempted to implement the select() TODO in the TableOperations API, but it requires a significant refactor of the backend. Test Plan: added test Reviewers: alexmojaki Reviewed By: alexmojaki Differential Revision: https://phab.getgrist.com/D3325	2 years ago
Paul Fitzpatrick	98f64a8461	(core) add grist.selectedTable.create/update/destroy/upsert to custom widget api ... Summary: This makes an equivalent of the /records REST endpoint available within custom widgets. For simple operations, it is compatible with https://github.com/airtable/airtable.js/. About half of the diff is refactoring code from DocApi that implements /records using applyUserActions, to make that code available in the plugin api. Test Plan: added tests Reviewers: alexmojaki Reviewed By: alexmojaki Differential Revision: https://phab.getgrist.com/D3320	2 years ago