> How about extending java.sql.ResultSet to implement > clojure.lang.Seqable instead? Now that we have this capability > wouldn't it be ideal to not have any more foo*-seq functions?
Since a ResultSet is also a resource that needs to be closed in a timely manner it might be clearer to follow the same pattern as line-seq. (with-open [^ResultSet rs (exec-query ...)] (doseq [row (resultset-seq rs my-naming-strategy)] (println (str "contact name: " (:name row))))) Allen > On May 5, 6:04 am, Sean Corfield <seancorfi...@gmail.com> wrote: >> I don't think it's flexible enough to attach this to the connection. I >> work with databases where some groups of tables really need different >> naming strategies than others so I would definitely want these >> conversions available per operation - which is how c.j.j naming >> strategies currently work so it would be easy enough for folks to >> build something like Phlex suggests on top of what's already in c.j.j. >> >> So it sounds like it would be useful to expose c.j.j's internal >> resultset-seq* function? >> >> And given it's default behavior matches the core version, exposing it >> with the same name seems reasonable too since it won't break anyone's >> code (right?). >> >> Sean >> >> >> >> >> >> >> >> On Wed, May 4, 2011 at 4:06 PM, Phlex <ph...@telenet.be> wrote: >> >> > On 3/05/2011 23:58, Allen Johnson wrote: >> >> >> IMHO c.j.j/resultset-seq should perform something like the following: >> >> >> ;; i want my columns as strings exactly how they are in the db >> >> (resultset-seq rs) >> >> (resultset-seq rs identity) >> >> >> ;; i want my columns as lower-case keywords >> >> (resultset-seq rs (comp keyword lower-case)) >> >> >> ;; i want my columns as upper-case symbols >> >> (resultset-seq rs (comp symbol upper-case)) >> >> >> With the existing c.c/resultset-seq, I found myself converting the >> >> keys back to strings in order to pass those results to some existing >> >> Java code and templates for further processing. Most of the time the >> >> lower-cased keyword keys were just fine. >> >> >> Just my $0.02 >> >> Allen >> >> > It would definitely be a plus to have some facilities for conversion >> > from/to >> > clojure coding standard. >> > Not only for result sets but also for update functions and so on. >> >> > I personally would prefer this as a default : >> > customer_id -> :customer-id (and the reverse) >> >> > In a perfect world, it indeed would be best to have some control over this. >> > Maybe add this context as parameters to the connection object ? >> >> > (with-connection {:classname "org.postgresql.driver" >> > :subprotocol "postgresql" >> > :subname (str "//" db-host ":" db-port "/" db-name) >> > :user user >> > :password password >> > :field-names {:from-sql pascal-case->clojure ; or something like >> > this : (field-name-converter-fn :underscores :clojure-keyword) >> > :to-sql clojure->pascal-case}} >> > (do-stuff)) >> >> > field-name-converter-fn being a multi-method returning a lambda that does >> > the conversion. One would be able to add his own methods, or simply use the >> > identity function. >> >> > Sacha > > -- > 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 -- 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