I've added an issue for getting access to generated SQL and possibly execution statistics.
On Sat, Apr 23, 2011 at 1:38 AM, Shantanu Kumar <kumar.shant...@gmail.com> wrote: > Some databases (under certain configuration) work only with case- > sensitive entity names. Converting them to all lowercase breaks under > those situations. It might have converted entities to lowercase at some point but it doesn't seem to now, at least as far as the SQL is concerned - but see next comment. > Also see related problems reported by others: > http://osdir.com/ml/clojure/2010-10/msg00290.html (sorry, can't find > it on the group.) Yes, resultset-seq does lowercase the column names and it doesn't translate between - / _ either. But that's not part of c.j.j so, whilst I may agree with the criticisms of it, I can't actually fix that :) Perhaps someone from Clojure/core could speak to resultset-seq's behavior? > Some databases allow multiple auto-generated columns in a table. > Inserts to such tables generates multiple keys - it probably makes > sense to return them as a map. So, my suggestion: return a map {column > => generated-value} per `insert`, and for `update-or-insert` it should > return just an empty map {} when it's actually an update. The current c.j.j behavior is to return a seq of vectors; each vector contains the update count and, if > 0, a map of the generated keys. If I restrict returning generated keys to single inserts, then I can just return a map of keys. If I allow for multiple inserts, I have to keep the update counts because if one of the set of inserts does not generate keys, you would need a way to detect that. Overall, I think simplicity leans toward only returning generated keys, as a simple map, for a single insert operation. Then the only question is whether inserts should automatically attempt to return a map of generated keys when there is a single insert. I'd lean to making that the default and, if people care, providing an optional argument to suppress it. Thoughts? >> > 7. The function for creating tables is non-portable across databases >> > -- make it known in the docstring >> Or work hard to make it more portable :) > How? :) Lowest common-denominator is not what a customer would pay the > database vendor for, and it's difficult to incorporate syntaxes for > major-if-not-all databases (which would still be non-portable). Well, create-table does minimal transformation on its arguments so you can specify: (create-table "adminUser" [ ["id" "int(11)" "not null" "auto_increment"] ... ["primary key" "(id)"]]) And that will generate: CREATE TABLE adminUser ( id int(11) not null auto_increment, ..., primary key (id) ) What you cannot do is provide any options after the columns specs - that's definitely a weakness. I've added an issue for that. I'd definitely be interested in suggestions for cleaner ways to specify column specs (although I'm more concerned with general queries than DDL operations). > Probably a reasonable set of types that map respectively to different > databases? What about indexes, primary keys, constraints etc? This > calls for a separate, dedicated library IMHO. It may be a good idea to separate out the DDL operations into a sub-library. Thoughts from others? clojure.java.jdbc.ddl perhaps? > The point here is to setup a generic configuration mechanism for > database libraries beyond c.j.j so that they can hook up their own > functions and intercept when necessary. As long as the configuration > can be contained in a map, I think it can serve libraries as well. Not > sure if the configuration mechanism should always be accompanied with > c.j.j hence my suggestion -- please consider it more of food for > thought rather than recommendation. If such a mechanism were added for c.j.j, I think it would have to be in effect for resultset-seq too since one of the behaviors I think people will want to modify is the mapping to / from entity names, right? I guess I need to see a more concrete example before I really grok what you're suggesting here. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
