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
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
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
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
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
+1
On Fri, Dec 3, 2010 at 10:25 PM, ka sancha...@gmail.com 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
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
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 keys in any way. This leaves resultset-seq's
behavior
,
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 keys in any way. This leaves resultset-seq's
behavior
+1
On Dec 1, 8:01 pm, Ryan Twitchell metatheo...@gmail.com 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
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
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?
On Fri, Oct 15, 2010 at 1:49 AM, David Powell djpow...@djpowell.net 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
2010/10/15 Mark Engelberg mark.engelb...@gmail.com
On Fri, Oct 15, 2010 at 1:49 AM, David Powell djpow...@djpowell.net
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
wrote:
Why does resultset-seq convert column names to all lower case? This
behavior is screwing me up (my column names are intentionally mixed
case) and I don't understand the reasoning.
Thanks,
Mark
--
You received this message because you are subscribed to the Google
Groups Clojure group
can set
with an optional flag?
On Sun, Oct 10, 2010 at 8:41 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
Why does resultset-seq convert column names to all lower case? This
behavior is screwing me up (my column names are intentionally mixed
case) and I don't understand
Why does resultset-seq convert column names to all lower case? This
behavior is screwing me up (my column names are intentionally mixed
case) and I don't understand the reasoning.
Thanks,
Mark
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Yeah this doesn't happen on using lazy-seq. Thanks!
Shantanu
On Sep 20, 8:52 am, Stephen C. Gilardi squee...@mac.com wrote:
On Sep 19, 2010, at 3:45 PM, Shantanu Kumar wrote:
I simulated a similar recursive call and found it
throws StackOverflowError at 5508 levels deep on a 32-bit Sun JVM
Hi,
While looking at the implementation of clojure.core/resultset-seq
function, I found there is a recursive call to 'thisfn' which isn't
loop-recur'ed. I simulated a similar recursive call and found it
throws StackOverflowError at 5508 levels deep on a 32-bit Sun JVM (not
server mode) on Windows
On Sep 19, 2010, at 3:45 PM, Shantanu Kumar wrote:
I simulated a similar recursive call and found it
throws StackOverflowError at 5508 levels deep on a 32-bit Sun JVM (not
server mode) on Windows 7.
Did your similar recursion include the lazy-seq form that wraps the
(apparently) recursive
Hi,
I want a function that takes byte array in zip format and returns
sequence of included ZipEntrys.
I wrote zipentry-seq based on clojure.core/resultset-seq as below.
(entries) returns sequence of included ZipEntrys and many nils, so I
added ad-hoc filter at the last.
Please advice me
On Mar 12, 1:32 pm, Ron Lusk ronl...@alum.mit.edu wrote:
Works for me: I just overwrote my copy of resultset-seq with one that
uses getColumnLabel, and I am now getting the results I expected from
complex queries (in Interbase, at least).
On Feb 23, 9:33 am, Rich Hickey richhic
Hi,
Would it be better if resultset-seq mapped column names like ITEM_ID
to :item-id rather than :item_id?
I am using a variation of Itay Maman's Application Context Pattern
which, among other things, keeps state in a map wrapped in a closure.
I have a lot of keywords being passed around
Works for me: I just overwrote my copy of resultset-seq with one that
uses getColumnLabel, and I am now getting the results I expected from
complex queries (in Interbase, at least).
On Feb 23, 9:33 am, Rich Hickey richhic...@gmail.com wrote:
Sounds good to me - any drawbacks to this? Does
...
and resultset-seq won't throw an exception. ?
Sounds good to me - any drawbacks to this? Does it require that the
columns be named explicitly?
Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post
On Feb 23, 8:33 am, Rich Hickey richhic...@gmail.com wrote:
Sounds good to me - any drawbacks to this? Does it require that the
columns be named explicitly?
I can't think of any drawbacks. When the column is not named
explicitly, getColumnLabel returns the same thing as getColumnName.
Rob
Hi,
How about having this function call .getColumnLabel instead
of .getColumnName. That way, you can do a join with duplicate column
names and rename them in the SQL query...
select name name1, name name2, ... from ...
and resultset-seq won't throw an exception. ?
Rob
If you create a SQL query that returns duplicate names, resultset-seq
throws an exception: java.lang.RuntimeException:
java.lang.IllegalArgumentException: Too many arguments to struct
constructor
i.e.
(let [rs (query select description,description from table)]
(resultset-seq rs
28 matches
Mail list logo
