prisma
Generic interface to obtain schema information
Loving quaint so far - we are using it to build an OData service in front of a database.
In our use case we are querying the database for schema information (list schemas, list tables, get column info). This can be done in both MySQL, SQLite and PostgreSQL using queries, but the interface slightly differs in each case (i.e. in SQLite you need to query the sqlite_master schema and use PRAGMA table_info(table_name), whereas in MySQL and PostgreSQL you would query the information_schema).
Having methods in quaint that list schemas/tables would be very convenient and not at all difficult to implement. Having a way to obtain column information would be even better (but would require that quaint 'understands' the type names returned by the database and map them to some common set of types to be actually useful).
How would you implement this? Adding to the Queryable trait is one option, but the trait is soon going to be quite bloated if we start adding methods.
The other would be to implement an AST extension for this. How would it look like?
What information the table list should contain? Could this also be extended for SQL Server (support being merged in a few weeks).
@do4gr this hits your territory about introspection. Do you have some ideas how this should look like?
Depending what data you want to get about your schema, the queries can get very complex. We have a heavily-used (by us) crate for reading schema information that could be interesting to you as a comparison point: https://github.com/prisma/prisma-engines/tree/master/libs/sql-schema-describer
How would you implement this? Adding to the
Queryabletrait is one option, but the trait is soon going to be quite bloated if we start adding methods.
It depends a bit on whether you think this is in scope at all for Quaint. I understand you strive to provide a clean, general interface to databases, but leave query generation up to the user (except for the syntactic details). I would completely understand if generating/executing introspection queries is considered out of scope (~it would make a good complementary library some day...~ Ah I see the sql-schema-describer module now, @tomhoule is linking to looks great!).
For Quaint I would not make it any more advanced than a few utility methods (I often find myself having to query a list of schemas/tables so this really would be a convenience, but for any more serious introspection you would probably go and query information_schema yourself anyway).
The other would be to implement an AST extension for this. How would it look like?
Well, except for SQLite they all implement information_schema. So an AST extension would just consist of utilty methods writing (and possibly executing) the information_schema queries for you.
What information the table list should contain? Could this also be extended for SQL Server (support being merged in a few weeks).
Just having the names (schema name + table name), as Vec<ast::Table>, would be great. Anything further is probably too database-specific to generalize in Quaint.
At the moment it still depends on prisma-value but that would be doable, I think. However we couldn't make strong backwards-compatibility commitments because it's still in flux.