Alex Shinn wrote:
The biggest issue I see with the sql egg right now is it currently
hard-codes all values, generating a new SQL expression every time.
You want it to be able to represent placeholder values (named or
just with a ?)
...
It makes more sense to integrate the SQL generation with the
backends from the start.
What you propose might get really complex.
Some database may allow prepared statements with a ? in place of
column names, while others don't.
How does the library know which replacement slots will be table names
and which will be literals, at prepared statement creation time,
before seeing the actual values?
Taking these decisions from the user and putting them into the library
means writing lots of code to do static analysis of the s-expr sql
language. Which is not a bad thing per se, but it would need to be
backend-specific, and I'm not sure most backend writers (if any at
all) would do it.
The DBI should just provide a standard way to compile prepared
statements, so that an improved sql egg could use prepared statements
across all DBs that support it. IMHO the key is lessening the burden
on the backend writer, while providing most features of modern DBs in
a consistent interface.
The issue isn't just with the actual query string generated either.
We may want the high-level interface to always allow the LIMIT and
OFFSET keywords to page results, even if the backend doesn't support
it, by emulating it on the client side.
Uhh, still more burden on the backend writer? I don't like the sound
of it. Besides, if you need limit and offset, you might as well
upgrade to another RDBMS.
Tobia
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
