Ah, but it is. I think what Ben tried to say is that the SQL queries
are something very 'unlanguagy'. If at all possible, we should keep it
as language-neutral as possible, not having to do
any
conversion is very useful. That doesn't mean we shouldn't try to
implement functions on top of the Query Dispacher so it can perform
the [ns_db getrow $db $sql] and maybe do some nice error handling,
fail-over, etc. Although we would have to be careful not to try to
re-invent the wheel.
It would be nice if the Query Dispatcher was something really
stand-alone, which would encourage porting it to other languages. I think
there is not much reason, if any, to tie it to (Open)ACS. If it's
possible I will use it for non-web and hybrid projects. I know too much
abstraction is bad for performance - but there are plenty projects
that try to run on different flavors RDBMS anyway.
I would also very much like it if we store some meta-data about the
query.
A return type for example would be very useful. Will it return
1-row, a row-set, one column (stuff it in a Tcl-list from the QD), a
single value or an ORDBMS object?
Next up is the parameter values,
typing them would be a handy (So we can, for example, handle the
QQ-ing of strings in the dispatcher).
Room for comments in would be good. I find SQL hard to read,
describing what it should return for a complex query should aide in
porting the module.
Maybe an approximation of
computational cost of the query (for billing or setting quotas on
those resources). And finaly some asserts (done with regular
expressions or something) to check input and output data, for
debugging purposes mostly.
Ben, I am willing to create the DTD for the XML document, if you don't
want to spend time on creating one yourself.
