[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A few comments about SchemeQL



Noel Welsh <noelw@dai.ed.ac.uk> writes:

> Below are a few ideas that popped into my head while looking at
> SchemeQL. I hope they're of help.

They are, thanks. Anyway, I'd like to comment on some of your
ideas.

> SrPersist is the only thing for now, but you don't want to be
> dependent on it. I think there are four layers:
> 
> - Driver (SrPersist at the moment)

You're right, I don't want SchemeQL to be too dependent on SrPersist,
but not doing so, would required a major re-write of SchemeQL. I'll
try to do it, though.

> - Connection pooling (essential for performance in large systems)
> - Translation from SchemeQL to SQL ('cause you will never model
> vendor-specific SQL quirk in SchemeQL)

These two are easier. :-)

> Imagine a world where SchemeQL can be used w/ SrPersist, native
> drivers (faster), flat text (convenience) etc.

Yup, that's a good idea. Nevertheless, using native drivers or flat
text *do* require a SrPersist-alike unit to provide a Scheme-level
API, SchemeQL could then use. I'll try to document what exactly such a
library should provide, and of course write a default one that will
simply call SrPersist's procedures.

> Selection
> ---------
> 
> I'd like a query to be first class object that could be parameterised,
> and combined w/ intersection, union, outer join and negation to create
> new queries.

SchemeQL implements the "SQL Minimum Grammar", which any
ODBC-compliant driver must support, and none of the above functions
are part of that grammar. Of course, I can extend SchemeQL to support
those functions, at the expense of needing the *driver* to support a
broader range of database operations (SrPersist does, so no problems
in the immediate future).

Making queries first class is appealing, nevertheless if the
underlying DBMS does *not* support inner/outer joins, etc,. doing them
at the Scheme level is a no-op, due to memory, and efficiency concerns.
This would be the case with plain text database systems, for
instance. But hopefully, nobody would use such a system with huge
tables.

SchemeQL already supports inner joins (using the `,' operator), an
extension of the SQL Minimum Grammar, so that transforming
intersection, and union into inner joins might be straight forward,
but then again, your DBMS, and ODBC driver must support inner joins.

Thanks again for your fine ideas, I'll try to implement them, and see
how that goes. BTW, I've been cleaning up the code (or the exact
opposite, YMMV :-> ) of SchemeQL, among other things SchemeQL is now a
unit, and if SrPersist works on your system, SchemeQL most likely will
too. You can find the latest version here:

        ftp://ftp.beta.fciencias.unam.mx/pub/solsona/schemeql

or

        ftp://abulafia.fciencias.unam.mx/pub/solsona/schemeql


--Francisco