launchbadge
WIP [next]: implement generalized query placeholders
@abonander
I have not looked at all of this change but if sqlx will parse the string passed to methods like query(), shouldn't we need a new native_query method to be able to support database specific SQL queries? Or will you intend to basically write an SQL parser that correctly parses every kind of supported databases' SQL flavour at the same time? (There are SQL features with their own syntax which are supported in one database but not in another etc.) If sqlx will starts to parse query strings it will need to have a way for users to opt out of that and send the database custom database specific "native queries" like it is in Java with native_query.
If sqlx starts parsing given "SQL strings" and generate another database specific one where do we stop and what separates this query language from a DSL (which from the looks of the documentation this crate is not?) like JPQL?
On the other hand can you actually support dynamically (e.g.: the database connection string is coming from an env variable) multiple databases without a DSL like JPQL when even the most basic stuff like query parameter syntax is different from database to database? It feels like you cannot actually be database agnostic dynamically and also not have a custom query language.
Or am I misunderstanding something? Isn't the: "... without a DSL." from the README refers to the lack of custom query language like JPQL? Or is it no problem to transform this crate into a state where it has its custom query language? Or how will these generalized query placeholders work? Will they use the old query() and alike methods?
This design does not fully parse the query strings. The only syntax it's aware of is string literals so it avoids parsing {} pairs inside strings, and that's pretty standard in SQL flavors.
The only database-specific thing it'll need to be aware of is which style of native placeholder the database uses.
I suggest reading the original proposal linked at the top if you haven't already.
Thanks that makes sense. In that case I understand why we can stay with using the same methods.
If sqlx later adds more support for providing generalized querying language support that is more invasive (like generalized function invocation, casting, LIKE query wildcards etc), it will probably make sense adding support for separate parsed and "unparsed, native queries".