Re: [Chicken-users] DBI

[Tobia Conforto]

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