Thanks for the comment. I also thought the same, so I don't blame people for thinking it's a terrible idea.
What's really exciting is that it gives reactivity, reloading, declarative state and a lot of optimizations almost for free, but as I haven't implemented them in PageQL yet, the advantages are less clear.
Wow, mod_plsql looks really cool, I didn't know about it.
From the replies I think it mainly went out of favour because of lack of reactivity. I could port PageQL to C/Postgresl/Mysql, but I don't think it would be sufficient for a modern application, as reactivity is expected nowdays. Still, I keep it in mind to leave this kind of development as an option in the future.
> I tried to learn from the original (pre-Adobe) ColdFusion, but make it closer to standard SQL.
Are you referring to querying a datasource, where the SQL is just passed to the external database engine, or to the ability to query an existing dataset using the embedded SQL engine?
Right now it's using Python DB API with SQLite, so it can be easily modified to use any database, as they are using the same standard Python API.
In the future though I'm planning to add reactive query support where it is really advantagous to have low latency between the PageQL rendering engine and the database.
For MySQL/PostgreSQL for example an extension would run much faster, and give back the results, that's why I don't want to add async / http downloading / scripting support inside PageQL, just keep it simple to implement / embed.
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).
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).
That's fun. I remember doing this ~2001 with some JSP tags. Everyone thought it was terrible idea but it was really productive tbh.
Thanks for the comment. I also thought the same, so I don't blame people for thinking it's a terrible idea.
What's really exciting is that it gives reactivity, reloading, declarative state and a lot of optimizations almost for free, but as I haven't implemented them in PageQL yet, the advantages are less clear.
Around the same time I built several line of business applications using Oracles mod_plsql. It was also very productive.
HTML + SQL + imperative PL/SQL, running inside the database, right next to the data.
Wow, mod_plsql looks really cool, I didn't know about it.
From the replies I think it mainly went out of favour because of lack of reactivity. I could port PageQL to C/Postgresl/Mysql, but I don't think it would be sufficient for a modern application, as reactivity is expected nowdays. Still, I keep it in mind to leave this kind of development as an option in the future.
> I tried to learn from the original (pre-Adobe) ColdFusion, but make it closer to standard SQL.
Are you referring to querying a datasource, where the SQL is just passed to the external database engine, or to the ability to query an existing dataset using the embedded SQL engine?
Right now it's using Python DB API with SQLite, so it can be easily modified to use any database, as they are using the same standard Python API.
In the future though I'm planning to add reactive query support where it is really advantagous to have low latency between the PageQL rendering engine and the database.
For MySQL/PostgreSQL for example an extension would run much faster, and give back the results, that's why I don't want to add async / http downloading / scripting support inside PageQL, just keep it simple to implement / embed.
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).
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).
PHP, is that you?