Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-11-15

Channels

#sql
<
2019-11-15
>
seancorfield01:11:55

@vale Your PostgreSQL issue is also fixed now on master -- there's a new, optional namespace next.jdbc.date-time that extends SettableParameter to provide automatic conversion to java.sql.Timestamp for java.util.Date, java.time.Instant, java.time.LocalDate, and java.time.LocalDateTime.

valerauko03:11:00

awesome you're a hero

seancorfield03:11:56

Download 1.0.10 and let me know how it goes.

seancorfield03:11:42

I still can't believe PostgreSQL can't do that conversion on its own... I mean, I verified the failure by adding tests (that only PostgreSQL failed!).

seancorfield03:11:30

H2 and SQLite support automatic Java Time conversion out of the box (which was a pleasant surprise). PostgreSQL doesn't (of course) but neither do Apache Derby or HSQLDB. I haven't tested MS SQL Server or MySQL for that (but I know at least MySQL supports java.util.Date conversion!).

seancorfield01:11:27

That'll be of interest I expect to anyone currently using Java Time types with next.jdbc.

seancorfield01:11:06

That means there are no more open issues for 1.0.10 so I'll release that either later tonight or some time tomorrow https://github.com/seancorfield/next-jdbc/milestone/6?closed=1

seancorfield03:11:05

seancorfield/next.jdbc 1.0.10 is up on Clojars. On cljdoc, there's a broken link in Getting Started (to Tips & Tricks, unfortunately) that is already fixed on master.

parrot 12
seancorfield03:11:22

I'll do a bigger announcement to various places later.

geek-draven08:11:09

Thanks @seancorfield really appreciate all your hard work

seancorfield08:11:18

@geek-draven Will that Statement support work for you, per the example in the docs? (jdbc/execute! (.createStatement con) ["... sql goes here ..."])

geek-draven08:11:14

@seancorfield yep, that should be perfect, I'm just about to get one of the devs to update the code they were working on to give it a go

seancorfield08:11:37

Cool. It's 1am here and I'm heading to bed but feel free to drop thoughts/feedback in this channel and I'll catch up with it on the morrow.

nielsk14:11:33

@seancorfield would it be theoretically possible to make a resultset processing function that returns a raw resultset in next.jdbc ?

seancorfield16:11:21

@nielsk I'll take a look when I'm at my desk in an hour or so.

seancorfield17:11:51

@nielsk OK, so the problem you'll have there is that the ResultSet object is only valid in the context of the open connection/statement from which it was retrieved -- both next.jdbc and clojure.java.jdbc close statements and connection after they're "done" which gives you a very limited window of opportunity to do anything useful with the ResultSet object. My recommendation would be to use plan and do everything you need with the results inside the reducing function you apply -- that is almost a raw ResultSet object, just wrapped in a thin veneer of Clojure hash map behavior.

seancorfield17:11:52

(for each row -- so you still couldn't get at the actual result set object there)

seancorfield17:11:06

Can you explain your use case so I can suggest alternative approaches?

seancorfield16:11:28

@U0522TWDA Good catch. Good job it's only a docstring! I'll fix as soon as I am at work!

👍 4
Jakub Holý (HolyJak)16:11:21

Thank you for the feature BTW, now I can delete a few lines of code :)

seancorfield18:11:28

Docstring updated on master. Thank you!

seancorfield17:11:51

@nielsk OK, so the problem you'll have there is that the ResultSet object is only valid in the context of the open connection/statement from which it was retrieved -- both next.jdbc and clojure.java.jdbc close statements and connection after they're "done" which gives you a very limited window of opportunity to do anything useful with the ResultSet object. My recommendation would be to use plan and do everything you need with the results inside the reducing function you apply -- that is almost a raw ResultSet object, just wrapped in a thin veneer of Clojure hash map behavior.