Preferences

bdcravens parent
Thanks for the response, but I was just curious about what you said about ColdFusion's SQL. Until it gave you the ability to run queries against already queried recordsets, it never had its own SQL dialect, but simply passed along SQL to the underlying adapter (I assume you're doing the same).

xiphias2
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).

This item has no comments currently.