-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide strategies for views #82
Comments
As I was exploring this: views seem really powerful, and we should do them. But also: having to reify something as a view seems a bit onerous. Could we make something work with just SQL queries? e.g. sometimes you want to write an ad hoc query that pulls in data from other tables, and then quickly take action based on that. We need a view so that we have a hook to hang on -- editing is currently driven through the row page, and queries don't have row pages, only views and tables do. But maaaaybe there is some wiggle room? eg imagine we could make: SELECT id, name, reviewed AS reviewed_editable FROM table and get That is, do some convention where we look for a rename of the base column to base column + _editable to light up the experience. We can get the query from grovelling in the request, which would let us figure out the pkeys. Ideally we'd be able to re-use the existing edit controls -- maybe they just need an Anyway, this is a bit of a digression. Let's stick with views for now, since they also offer interesting permissions controls for collaboration capabilities. (Presumably a raw SQL query would just be subject to the permissions of the base table?) |
Views also have easy sorting and filtering, whereas queries don't (granted, you can "just" edit the query) |
...hm, if you do make a view, there's not currently a way to get to the row of the view, we'd have to add that in. |
I'm going to solve my immediate problem using a query that links to the underlying base table for now, and think on which direction to pursue for dux itself. I hadn't really considered inline editing in ad hoc queries, but it's starting to seem pretty attractive. |
Views are editable in SQLite if you define triggers for them.
Should we automatically create such triggers for all views for which we can (ie any view which is based on a single table)? I think no.
Instead, admins should be able to pick which operations to support: insert, update, delete or some combination.
Should this be done entirely via comments in schema? This is appealing, as it means no special UI is needed to start (we could layer a UI on later)
That seems reasonable! Might we want other abilities? And can they be layered in later?
Other useful things:
/* insert column = new.column + 1 */
/* update column = new.column + 1 */
/* after-insert: insert into audit_table(x, y, z) values (new.x, new.y, new.z); */
/* after-insert: insert into audit_table(before, after) values (old_as_json, new_as_json); */
/* after-insert: insert into audit_table(changes) values (diff_as_json); */
/* insert-where (select count(*) from table where actor = current_actor()) < 5 */
/* delete-where actor = current_actor() */
I suspect these can all be layered in after the fact.
The text was updated successfully, but these errors were encountered: