[cl-rdbms-devel] Convenience over extensibility? Or: How to build on top of hu.dwim.rdbms?

[Attila Lendvai]

> While the sql reader syntax e.g. [select * table] is convenient for humans
> it doesn't allow for being used by other functions or does it?


(read-from-string "") as a last resort, otherwise it reads into a CLOS
based AST anyways and that you can construct programmatically.

note: the SQL reader and AST stuff is on the TODO to be moved into
hu.dwim.quasi-quote and rebased on its infrastructure. but it's not
high priority, and wouldn't change anything conceptually...


> In my opinion such a sql reader syntax is nice to have but not being able to
> extend the software
> through the use of functions is disastrous in my eyes. I have the feeling
> that we create two camps here, one the developers
> and the other the users. Personally I don't like that distinction and would


it's a library for developers, there are no two camps. it's only developers...


> much prefer to make the possibility of extending
> the software through the use of functions as easy as possible for the so
> called "user".
>
> With that in mind I find myself using internal function and classes from the
> hu.dwim.rdbms package
> ( e.g. sql-and, sql-sequence-nextval-column, sql-identifier,
> sql-all-columns, sql-= )
> and writing wrapper functions for it e.g.


we didn't put too much effort into deciding what should be exported
and be part of a long-time API, and what isn't. but while (not) doing
that we were on the conservative side...


> What do you think about what I just said. Did I go wrong somewhere?
> And if the above is really an issue, any ideas as how to handle it?


define your own convenience functions? if they seem to be generally
useful, propose an extension (but to spare some time, the naming
convention you use in your functions will not go though :)


> Right now I did create another system and package called
> hu.dwim.rdbms.oracle.ext for things like the above.
> (The names above are not carved into stone tablets. I often change my mind
> before I settle for certain names and yes,
>  often the wrappers seem unnecessary but I don't want to change the package
> definition of hu.dwim.rdbms
>  and/or prefer shorter names.)


that's a good compromise and leaves you the freedom to use
names/shortcuts you prefer. even if such utils were provided by the
main lib, it would not please everyone... so the way to go is to
provide a preferably complete skeleton of functionality using
descriptive and sometimes long names, and let people do their
shortcuts if the need be.

we stick to long names (and use fuzzy completion in slime).

-- 
 attila