> > 1. Allow _ (underscore) in field names > > This already seems to work. I just tested the following - can you elaborate:
Yes, I tested this and it seems to work now. Not sure where I noticed earlier where it was not working. My bad. > > I agree that translating - / _ would be more idiomatic. I'm not sure > it needs to be more sophisticated than that tho'... > > > 2. Provide a mechanism to show the SQL being executed (configurable, > > so that it can be turned off) > > Good idea. Even better, a way to access statistics about the prepared > statement after execution - timing etc? Yes, that would be an add-on value to show how are the queries performing. > > > 3. Allow users to flexibly convert from Clojure name to DB entity name > > Right now you can specify :name or "name" in arguments. Records come > back with entity names as keywords. Could you elaborate on what you'd > want to see here, beyond the - / _ translation mentioned above? > > > 4. Allow users to flexibly convert from DB entity name to Clojure name > > (this affects resultset-seq) > > As per 3. could you give an example use case? I saw what your library > provides but I'm not entirely sure how many folks would need that > flexibility. What do others think? Some databases (under certain configuration) work only with case- sensitive entity names. Converting them to all lowercase breaks under those situations. Also see related problems reported by others: http://osdir.com/ml/clojure/2010-10/msg00290.html (sorry, can't find it on the group.) > > > 5. Provide a mode to prevent write operations > > Interesting idea but isn't that better handled by grants on the user > accessing the database? The intention here is to proactively prevent errors from a development standpoint. And then, some databases do not support permissions -- however, the notion of read-only vs writes is common in database development and can be useful to have. > > > 6. An INSERT function that returns the generated key(s) > > The current clojure.java.jdbc does this (I added a first cut of it as > part of the initial new version but it needs some streamlining). I was > disappointed the original c.c.sql just returned nil from insert > operations so I changed it to return a sequence of vector pairs > containing update counts and the resultset-seq map from the generated > keys. It's ugly right now so I'm looking for input there. > * Do we need the update counts? > * Do we need the map? > * Or just the key values? > * For multiple inserts, do we want to return a sequence of generated > keys, one per insert? > * Should there be a specific method to insert (one set of values | one > record) that returns keys? > * Or should it simply default to that for insert operations that have > a (single set of values | single record). > > My personal feeling is that it should return just the key values, in a > vector, one per inserted record, with an option to turn it off, per > insert operation). Maybe as a convenience, if you only insert one > record, you get back just a key, rather than a vector of one key? 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. Again, batch- inserts do not return generated keys on all JDBC drivers (notable exception is MySQL, on which it does). > > > 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). 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. > > I am sure others will have additional points to share. I would suggest > > the configuration aspect be split into a separate library from > > c.c.sql. Even more importantly, I think it needs a certain degree of > > incubation before being promoted to clojure.java.jdbc. > > Could you elaborate on the deficiencies you see in the configuration > part of c.j.j? I think your library provides some nice syntactic sugar > on creating the DB spec but since most projects do it only once per > application, I'm not sure that needs to be in standard library? 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. Regards, Shantanu -- 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
