> 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.
(inc)
> So it sounds like it would be useful to expose c.j.j's internal
> resultset-seq* function?
This has my vote.
> And given
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 wrote:
>> I don't think it's flexible
olks 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 nam
ly 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
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
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
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 y
+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
+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
x27;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-s
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'
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
set
> with an optional flag?
>
> On Sun, Oct 10, 2010 at 8:41 PM, Mark Engelberg
>
>
>
> 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
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
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&
Yeah this doesn't happen on using lazy-seq. Thanks!
Shantanu
On Sep 20, 8:52 am, "Stephen C. Gilardi" 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 (not
> >
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,
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
ser
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 to
On Mar 12, 1:32 pm, Ron Lusk 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 wrote:
>
>
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 key
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 wrote:
> Sounds good to me - any drawbacks to this? Does it require that
On Feb 23, 8:33 am, Rich Hickey 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
--~--~-~--
On Feb 22, 7:59 pm, Rob wrote:
> 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 ...
>
&
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. ?
Has anybody else hit this?
I just did. Its not tricky to alter resultset-seq to return maps with
qualified keys:
(defn resultset-seq
"Creates and returns a lazy sequence of structmaps corresponding to
the rows in the java.sql.ResultSet rs"
[#^java.sql.ResultSet rs]
(let [rs
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")]
(re
31 matches
Mail list logo
