I see, yes, right now I'm doing the same, just passing the SQL query along with a bit of preprocessing, like changing :headers.something to :headers__something as the bindings don't accept dots.
Regarding temporary resultsets I'm thinking of adding a #view command instead that creates an SQL view that is shared between invocations and doesn't accept parameter bindings.
The main reason why I want my own full SQL query parsing is because of the reactive views: I want to be able to show 1000 long tables and when a change to a row is made from outside, be able to react to the change without reading the whole 1000 long table again, just push that 1 line change with the websocket. This can be useful for chatbots/chats/live infinite scrolling where the content changes / new content comes in.
Still, it just constructs new SQL queries that are easy to optimize, like SELECT * from (SELECT * FROM T) where id=1 (SQLites optimizer is rewriting these queries quite fast, so I don't want to write my own optimizer, just query builder for reactive SQL).
Regarding temporary resultsets I'm thinking of adding a #view command instead that creates an SQL view that is shared between invocations and doesn't accept parameter bindings.
The main reason why I want my own full SQL query parsing is because of the reactive views: I want to be able to show 1000 long tables and when a change to a row is made from outside, be able to react to the change without reading the whole 1000 long table again, just push that 1 line change with the websocket. This can be useful for chatbots/chats/live infinite scrolling where the content changes / new content comes in.
Still, it just constructs new SQL queries that are easy to optimize, like SELECT * from (SELECT * FROM T) where id=1 (SQLites optimizer is rewriting these queries quite fast, so I don't want to write my own optimizer, just query builder for reactive SQL).