|
|
|
|
|
by snthpy
238 days ago
|
|
Yeah, we deliberately left out DML to focus on DQL exclusively. I also find that appealing from a philosophical angle since it allows PRQL to remain completely functional. I haven't thought about DML too much but what I could envision is an approach like the Elm or React architecture where you specify a new state for a table as a PRQL query and then the compiler computes the diff and issues an efficient update. For example DELETE FROM table_name WHERE id = 1;
would be something like table_name = from table_name | filter id != 1
SQL: INSERT INTO table_name (id, name) VALUES (1, 'Jane');
PRQL: table_name = from table_name | append [{id=1, name='Jane'}]
Update is the trickiest to not have clunky syntax. For example what should the following look like?SQL: UPDATE table_name SET name = 'John' WHERE id = 1;
I can think of `filter` followed by `append` or maybe a case statement but neither seems great.Any ideas? |
|