[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A few comments about SchemeQL
Below are a few ideas that popped into my head while looking at
SchemeQL. I hope they're of help.
Architecture
------------
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)
- Connection pooling (essential for performance in large systems)
- Translation from SchemeQL to SQL ('cause you will never model
vendor-specific SQL quirk in SchemeQL)
- SchemeQL
Imagine a world where SchemeQL can be used w/ SrPersist, native
drivers (faster), flat text (convenience) etc.
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.
Example:
Two tables in the database, one named programmers, the other
personnel:
Programmers Personnel
employee_id language employee_id employee_name
---------------------- ---------------------------
1 Scheme 1 J. A. Hacker
2 C++ 2 M. Leak
3 B. Boss
To select all programmers:
(define programmers (query 'programmers '(employee_id language)))
To select all personnel:
(define personnel (query 'personnel '(employee_id employee_name)))
To select all (employee_name language) pairs:
(define personnel-and-language
(intersect programmers personnel
'(= (programmers employee_id)
(personnel employee_id))))
To select all (employee_name language) pairs for a given
language. That is, a query parameterised over an argument:
(define personnel-by-language
(query (language) personnel-by-language
'(= (personnel-by-language language) language)))
Then proceed to give all the Scheme programmers a raise:
(give-raise-to (db-find (personnel-by-language "Scheme")))
And send the C++ programmers to eternal damnation...
I admit, I'm not sure how this would be implemented...
cya,
Noel
--
Noel Welsh
http://www.dai.ed.ac.uk/~noelw/ noelw@dai.ed.ac.uk