You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The user could always send their queries one-by-one (which is why this is a P2, if we don't have time for it, we can change the docs to mention that), but we can use this as a basis to create implicit mini-transactions, i.e.:
CREATETABLEstagingAS (...);
DROPTABLE production;
ALTERTABLE staging RENAME TO production
which would get executed by Seafowl inside of a transaction on the catalog. The effect would be that other queries will always see the production table, even while it's being recreated.
The semantics would be:
return the output of the last query
for queries that aren't the last one, only execute writing queries (no point in executing RO queries if we won't see their results)
The text was updated successfully, but these errors were encountered:
Several examples in the docs (e.g. https://www.splitgraph.com/docs/seafowl/guides/baking-dataset-docker-image#building-a-docker-image that uses #39) require being able to pass multiple queries in a single command. We currently don't allow that (copied from DF): https://github.com/splitgraph/seafowl/blob/main/src/context.rs#L551-L558
The user could always send their queries one-by-one (which is why this is a P2, if we don't have time for it, we can change the docs to mention that), but we can use this as a basis to create implicit mini-transactions, i.e.:
which would get executed by Seafowl inside of a transaction on the catalog. The effect would be that other queries will always see the
production
table, even while it's being recreated.The semantics would be:
The text was updated successfully, but these errors were encountered: