Right now, the REST API is just an interface to view/change the state of things right now (CRUD). But with version control now in place, there's a lot more awareness and intelligence available to integrate in. We need to integrate bundle-awareness into endpoint, generally. #72 touches on it but it is just the tip of the iceberg.
Examples of where it would be nice/essential:
Building the commit history inspector. Right now there isn't a good way to see what was in a particular bundle at a particular commit without checking it out.
Widget copy in the IDE - The row isn't being tracked in the current bundle, it goes into the untracked row heap instead, because I didn't write a bunch of boilerplate to track the copied row. Should just be a flag.
Looking at version history of any row. There should be an API for this, not a bunch of client-side garbage code that one-offs inspecting the commit tree over and over
Operational changes:
row_insert / rows_insert
Needs the ability to specify that the new row should be tracked, staged, or maybe even committed, and by which bundle. Track-on-insert is very often the desired behavior. Stage-on-insert is less common but seems like it could be useful. Commit-on-insert is weird, but we might as well make the option available for say a streaming database or a commit-based chat.
The above could also be accomplished, alternately, by setting up table-wide auto-tracking rules: "All inserts into this table are tracked by this bundle." Not sure this is a good idea though, because nobody "owns" a particular media type. Could be useful in a single user environment.
row_update
Updating a row that is in a bundle (tracked) could auto-stage the update. Not much here.
row_delete / rows_delete
Deleting could also auto-stage the delete. Also uninteresting.
row_select / rows_select / field_select
endpoint.row_select() takes a row_id, but it could also take a commit_id to grab the value at a previous commit, or a modifier that says "give me the HEAD version, not the working copy version." It could take version ranges (once we have version tags), etc. rows_select takes an args object for things like where clauses, which would be very strange to handle because it would need to somehow run a where clause against a not-checked-out version. Might be challenging. Checkout + rollback?
rows_select_function
This could actually take a previous version of the function which would be pretty crazy. Not sure how to pull that off though.
Or it could run against a previous version of the database. Also quite complex.
Right now, the REST API is just an interface to view/change the state of things right now (CRUD). But with version control now in place, there's a lot more awareness and intelligence available to integrate in. We need to integrate bundle-awareness into endpoint, generally. #72 touches on it but it is just the tip of the iceberg.
Examples of where it would be nice/essential:
Operational changes:
row_insert/rows_insertNeeds the ability to specify that the new row should be tracked, staged, or maybe even committed, and by which bundle. Track-on-insert is very often the desired behavior. Stage-on-insert is less common but seems like it could be useful. Commit-on-insert is weird, but we might as well make the option available for say a streaming database or a commit-based chat.
The above could also be accomplished, alternately, by setting up table-wide auto-tracking rules: "All inserts into this table are tracked by this bundle." Not sure this is a good idea though, because nobody "owns" a particular media type. Could be useful in a single user environment.
row_updateUpdating a row that is in a bundle (tracked) could auto-stage the update. Not much here.
row_delete/rows_deleteDeleting could also auto-stage the delete. Also uninteresting.
row_select/rows_select/field_selectendpoint.row_select()takes arow_id, but it could also take acommit_idto grab the value at a previous commit, or a modifier that says "give me the HEAD version, not the working copy version." It could take version ranges (once we have version tags), etc.rows_selecttakes an args object for things like where clauses, which would be very strange to handle because it would need to somehow run a where clause against a not-checked-out version. Might be challenging. Checkout + rollback?rows_select_functionThis could actually take a previous version of the function which would be pretty crazy. Not sure how to pull that off though. Or it could run against a previous version of the database. Also quite complex.