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?
-Jeff
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
