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
Insert across tables in one atomically consistent set. Receives deep object as input, walks from deepest leaves to root, inserts each object into corresponding table.
But how should report the ids and versionstamps of the nested rows? Array of Result with additional table name entry?
Deep insert is complex to implement, needs to pick apart deep input object, generate the ids and match them up, just to stitch it back together at query time later. It largely defeats the purpose of relational data storage, since can't link new data to existing data, must always insert together, could almost just store the whole data as JSON if not for ability to query only part of it. Also cumbersome for user to define duplicate type hierarchy for input types and output types.
Better to let user build the relations. Just somehow ensure consistency... Would need to give up generating ids for user, instead let the user generate random UUIDs in advance, allow to insert multiple at same time, throw if any id already exists.
Could accept multiple rows in a mutation, and multiple mutations in a request. The mutations must all be committed in one atomic transaction. Order doesn't matter since there are no foreign key constraints in Deno KV, and atomicity makes either all succeed or all fail. Inserting valid references is up to the user?
Insert across tables in one atomically consistent set. Receives deep object as input, walks from deepest leaves to root, inserts each object into corresponding table.
But how should report the ids and versionstamps of the nested rows? Array of Result with additional table name entry?
Deep insert is complex to implement, needs to pick apart deep input object, generate the ids and match them up, just to stitch it back together at query time later. It largely defeats the purpose of relational data storage, since can't link new data to existing data, must always insert together, could almost just store the whole data as JSON if not for ability to query only part of it. Also cumbersome for user to define duplicate type hierarchy for input types and output types.
Better to let user build the relations. Just somehow ensure consistency... Would need to give up generating ids for user, instead let the user generate random UUIDs in advance, allow to insert multiple at same time, throw if any id already exists.
Could accept multiple rows in a mutation, and multiple mutations in a request. The mutations must all be committed in one atomic transaction. Order doesn't matter since there are no foreign key constraints in Deno KV, and atomicity makes either all succeed or all fail. Inserting valid references is up to the user?
The text was updated successfully, but these errors were encountered: