Official web-based GUI client for evitaDB e-commerce database. It is built to help developers who use evitaDB with exploring and debugging their domain structure and data. Besides standard query executing, it also supports multiple no-code tools to quickly navigate through domain structure, docs and data without needing to write any queries.
It would be very helpful if evitaLab supported both read and WRITE operations. Currently, only read operations (in strictly GUI tools) are supported. In the future, we would like to support write operation as well. The main 2 areas are:
entity viewer - entity data mutations
schema viewer - schema mutations
I think we use evitaDB's mutation objects for this directly. This means that developer actions in the UI will generate evitaDB's mutations that can then be directly applied to an evitaDB server. Also, the developer could review the generated mutations both for verifying the actions and potentially learning what mutations are available and how they are used.
Here is a proposal how the entity editing could look like. When any mutation is created, a toolbar at the bottom of screen would be shown with details and actions about the mutations.
After expanding the toolbar, an overview of created mutations would be shown with same actions. The mutations would be readonly list.
These mutation would be tab-specific, which means if a developer has multiple entity viewer tabs open at the same time, each would have its own set of mutations.
Updating values
Change value will be done using the fetched raw value. The editing will be done either in a cell itself or the detail previewer. The biggest problem would be probably lists, where we will need some list editing actions as well (adding, removing, moving items).
When a value in grid cell is changed by the developer, the value needs to be somehow written into the rendered entity until the dataset is refetched. In parallel, a appropriate mutations need to be generated.
While there are mutations present, the dataset cannot be allowed to be refetched (page change, property selection change, query change, etc.). When a developers does action that would trigger refetch of dataset, a warning dialog needs to be shown to cancel the operation or discard mutations.
If the mutations are saved by the developer, the entire dataset is refetched with the newly updated data.
Rendered entities will need to have writable properties (where it is possible to generate mutations). Values of these properties will need to be somehow replaced based on changes in UI.
Generating mutations
For each change a appropriate mutation will be generated and added to a list of changes to save. In some case, like changing value of non-list attribute, we should be able to store mutation only for the newest change, not all the changes a developer has done to the attribute.
It would be very helpful if evitaLab supported both read and WRITE operations. Currently, only read operations (in strictly GUI tools) are supported. In the future, we would like to support write operation as well. The main 2 areas are:
I think we use evitaDB's mutation objects for this directly. This means that developer actions in the UI will generate evitaDB's mutations that can then be directly applied to an evitaDB server. Also, the developer could review the generated mutations both for verifying the actions and potentially learning what mutations are available and how they are used.
Here is a proposal how the entity editing could look like. When any mutation is created, a toolbar at the bottom of screen would be shown with details and actions about the mutations.
After expanding the toolbar, an overview of created mutations would be shown with same actions. The mutations would be readonly list.
These mutation would be tab-specific, which means if a developer has multiple entity viewer tabs open at the same time, each would have its own set of mutations.
Updating values
Change value will be done using the fetched raw value. The editing will be done either in a cell itself or the detail previewer. The biggest problem would be probably lists, where we will need some list editing actions as well (adding, removing, moving items).
When a value in grid cell is changed by the developer, the value needs to be somehow written into the rendered entity until the dataset is refetched. In parallel, a appropriate mutations need to be generated.
While there are mutations present, the dataset cannot be allowed to be refetched (page change, property selection change, query change, etc.). When a developers does action that would trigger refetch of dataset, a warning dialog needs to be shown to cancel the operation or discard mutations.
If the mutations are saved by the developer, the entire dataset is refetched with the newly updated data.
Rendered entities will need to have writable properties (where it is possible to generate mutations). Values of these properties will need to be somehow replaced based on changes in UI.
Generating mutations
For each change a appropriate mutation will be generated and added to a list of changes to save. In some case, like changing value of non-list attribute, we should be able to store mutation only for the newest change, not all the changes a developer has done to the attribute.