> 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
