Hi, On Oct 29, 1:15 pm, Miron Brezuleanu <mbr...@gmail.com> wrote:
> The pros I see are the ability to construct the data structure using > all the tools Clojure/Lisp offer in this area (quasiquotation and its > many friends, for instance). The ability to output code that is pretty > printed in a customized way is also a big plus (I care a great deal > about the readability of the generated code). Also, the SQL flavor > could be a pretty printing parameter - thus making it possible to > write code that will run on many RDBMSs - but I'm not very hopeful > about this, as differences between SQL dialects often go beyond > syntax. > > Cons: I'm afraid of getting the SQL generating syntax wrong and making > the data structures used for generation ugly. But I guess that can be > fixed by iterating a little. :-) ClojureQL[1] does that to some extent. Currently MySQL and Derby are supported as backends, Postgres to some extent (so it has issues, IIRC). The generation part consists of multimethods "compiling" the defined queries into JDBC PreparedStatements. Up to now we managed to hide the backend as much as possible, but the feature set of ClojureQL is still limited. So my suspicion is that the backend will leak through eventually... But we'll see. Nice effect: ClojureQL allows FULL JOINs with a Derby backend. Derby does not support FULL JOIN. Sincerely Meikel [1]: http://gitorious.org/clojureql --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
