> 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
> 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
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 wrote:
> I don't think it's flexible enough to attach this to the connection. I
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
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 keyw
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 upp
Since this thread from October focused on clojure.core/resultset-seq,
I thought I'd bump it again in the context of the (new)
clojure.java.jdbc library (formerly clojure.contrib.sql).
In order to support naming strategies, c.j.j uses an internal,
modified copy of resultset-seq that allows you to c
+1
On Fri, Dec 3, 2010 at 10:25 PM, ka wrote:
> I'm also stuck with the same issues: 1. no option to get string keys
> 2. I don't understand, why do libs go through the trouble of
> downcasing ?
>
> Having said that I totally agree with the point Ryan makes: >> A
> greater feature of clojure is i
I'm also stuck with the same issues: 1. no option to get string keys
2. I don't understand, why do libs go through the trouble of
downcasing ?
Having said that I totally agree with the point Ryan makes: >> A
greater feature of clojure is its extensibility. What I am after is a
generalization of t
Sean,
I entirely agree that the use of keywords as map keys is a feature of
clojure (and a great one, at that), and that converting result set
column names to keywords is a feature of resultset-seq. A greater
feature of clojure is its extensibility. What I am after is a
generalization of the func
+1
On Dec 1, 8:01 pm, Ryan Twitchell wrote:
> Hi all,
>
> I'm not too happy with how resultset-seq down-cases column names and
> turns them into keywords, as I would prefer to work with string keys
> in some cases. I came up with the following change to give the caller
> a choice to remap column
Using keywords in the resultset map is a feature. It is very common
to write something like this;
(map :your-column results)
This takes advantage of the fact that keywords implement IFn. To the
best of my knowledge SQL isn't case sensitive, downcasing the column
names makes sense too, since it
2010/10/15 Mark Engelberg
> On Fri, Oct 15, 2010 at 1:49 AM, David Powell
> wrote:
> > I'm in favour of down-casing - at least by default. Some processing is
> going to happen anyway, as column names might contain spaces, which wouldn't
> > be allowed in keywords.
> >
> > --
> > Dave
>
> One of
On Fri, Oct 15, 2010 at 1:49 AM, David Powell wrote:
> I'm in favour of down-casing - at least by default. Some processing is going
> to happen anyway, as column names might contain spaces, which wouldn't
> be allowed in keywords.
>
> --
> Dave
One of the more significant nuisances in Clojure/J
On Thu 14/10/10 20:58 , Mark Engelberg mark.engelb...@gmail.com sent:
> Since no one chimed in with support or reasoning for resultset-seq's
> current lower-casing behavior, can we discuss changing it to
> case-maintaining behavior, or at least make it something you can set
> with an optional flag
+1 Sounds good.
Regards,
Shantanu
On Oct 14, 11:58 pm, Mark Engelberg wrote:
> Since no one chimed in with support or reasoning for resultset-seq's
> current lower-casing behavior, can we discuss changing it to
> case-maintaining behavior, or at least make it something you can set
> with an opti
Since no one chimed in with support or reasoning for resultset-seq's
current lower-casing behavior, can we discuss changing it to
case-maintaining behavior, or at least make it something you can set
with an optional flag?
On Sun, Oct 10, 2010 at 8:41 PM, Mark Engelberg
wrote:
> Why does resultset
17 matches
Mail list logo
