Question about conceptual model of how render-related select's implemented

[3n-mb]

Let's go through an example, and tell if understanding is correct, pointing to respective code.

We have in file two statements:

SELECT
  'chart' as component,
  'Quarterly Revenue' as title,
  'area' as type;

SELECT
    quarter AS x,
    SUM(revenue) AS y
FROM finances
GROUP BY quarter

These get fed into database via driver. And returned tabulated data,
first

component	title	type
chart	Quarterly Revenue	area

and second

x	y
... rows	...rows

Renderer then interprets these tabulated structures to produce html, in this case.

Is this a correct impression?

In the above example renderer gets display/rendering structure from the first table.
The first table is formed by db from original sql select. Is this correct?

[lovasoa]

Yes, that's all correct ! If you want to dig into deeper details about how sqlpage works, you should check out this section of our README file on github.

In the example above, the first select query is so simple that it will be optimised away by sqlpage; it will not even be sent to the database, and sqlpage will immediately recognize that it needs to open the handlebars template for the chart component and start rendering it with the parameters

{
  "title": "Quarterly Revenue",
  "type": "area"
}

It will render it until the line that says {{~#each_row~}}, and immediately send the beginning of the page to the browser.

Then it will process the second query. This time it is not a simple query that can be optimised away, so SQLPage will send it to the database :

SELECT
    quarter AS x,
    SUM(revenue) AS y
FROM finances
GROUP BY quarter

The database will then start returning rows, one by one. For each new row, sqlpage will render the part of the component template that is between {{~#each_row~}} and {{~/each_row~}}, passing it the data from the returned row, and send it to the browser.

When the database says it is done with the query and there is no more rows to process, sqlpage finally renders the last part of the template (after {{~/each_row~}}) and sends it to the browser.

[3n-mb]

Nonetheless, neither picture in a readme, nor text communicate the beauty of a hack: giving essentially a constant to db to massage it into tabular form. I love this hack. But, this hack forces one into deflecting a meaning of SELECT.
SELECT selects! SELECT doesn't render, doesn't display.
The confused will not get sqlpage. I am one of the confused, but I am also persistent, making it a smaller pool of users. Hence, related point: #310

[3n-mb]

I see you saying, with future tense: "the first select query is so simple that it will be optimised away by sqlpage; it will not even be sent to the database".
In "future" and "optimized". Let's not get optimized into a local maxima of a design space. When you get sql parsing thingy, extend SQL for rendering (#310) 🙏 , rendering and further processing.

[3n-mb]

My bad. I miss-interpreted the "future" tense.
This test line

SQLpage/src/webserver/database/sql.rs

Line 715 in e93db08

assert_eq!(

in /webserver/database/sql.rs looks like usage of function that dives into SQL itself.
In other words sqlpage already has a machinery for specific handling of different sql statements. Ha. Then, what about #310 ?

[lovasoa]

The future tense is stylistic, SQLPage does already optimize away trivial queries, no matter whether they are selecting a component or data inside it.

I understand your initial reaction: SQLPage's approach is quite unconventional. However, I greatly encourage you to actually try SQLPage, and maybe have a look at the examples to understand the flexibility that using sql both for component selection and data hydration offers.

If you have an idea for an app, I'd love to hear your feedback after you try to build it with SQLPage!

[lovasoa]

in /webserver/database/sql.rs looks like usage of function that dives into SQL itself.
In other words sqlpage already has a machinery for specific handling of different sql statements. Ha. Then, what about #310 ?

I hadn't seen this comment. The line you are quoting is a test that checks the "simple select statement optimization". It does not change the SQL syntax or semantics, but it avoids having to send a SQL query to the database and wait for the database to respond when the results can already be deducted locally.