<< Back to previous view

[JDBC-63] Rename and expose db-with-query-results* Created: 26/Jun/13  Updated: 01/Jun/16  Resolved: 03/Nov/13

Status: Closed
Project: java.jdbc
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Justin Kramer Assignee: Sean Corfield
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File resultset.patch    
Patch: Code


I wanted to leverage java.jdbc but provide my own result-set-seq function. The only way to do that was to use alter-var-root, reach into private functions, and other such hacks.

The attached patch renames db-with-query-results* to db-with-result-set*, makes it public, and makes its func expect a ResultSet.

This separates result set processing from query execution. I.e., I can ask the library to execute some SQL against a DB spec, return a ResultSet, and then I'm free to process it as I see fit.

All tests pass.

Comment by Sean Corfield [ 26/Jun/13 5:27 PM ]

I can't say I like that approach. I really don't want to expose the ...* implementation functions. Can you explain what you needed to do differently in your result-set-seq function? Making that extensible by some other approach seems like a better way to tackle this...

Comment by Justin Kramer [ 26/Jun/13 5:48 PM ]

Pasting from our chat on IRC:

<jkkramer> I was initially thinking that (I have a use case in mind I'll explain) but thought this approach allowed for maximum flexibility for callers
<jkkramer> my particular use case is I wanted custom column labels
<jkkramer> which could be accomplished with a custom-label keyword arg or similar to result-set-seq, which is a function that takes rsmeta and idx
<jkkramer> however – i also wanted to be able to return additional per-column metadata such as the table name, which could be used later on to e.g. create nested hash map results. it starts getting complicated to rely on result-set-seq. being able to write my own ResultSet-processing function would be nice
<jkkramer> but i don't want to have to bother with connections, prepared statements, etc. just ResultSet processing

Comment by Sean Corfield [ 15/Sep/13 3:04 PM ]

FWIW, I just ran into a situation where I would like to be able to return a raw ResultSet from query so I'll have to give this some thought. Won't make 0.3.0 tho'...

Comment by Justin Kramer [ 16/Sep/13 6:55 AM ]

Just to reinforce the point: I don't see it as exposing implementation details so much as exposing the host – i.e., JDBC building blocks. Being able to process a ResultSet without having to manage the connection details would be extremely useful to me. I can make do until 0.4.0+ though.

Comment by Sean Corfield [ 03/Nov/13 10:41 PM ]

I've decided to incorporate a variant of this (since I was in messing with the guts of the query function anyway).

db-with-query-results* is now a public function called db-query-with-resultset but otherwise does exactly what you wanted, based on your patch.

Comment by Justin Kramer [ 04/Nov/13 2:15 PM ]

Excellent! Thanks, Sean. I'll be taking beta1 for a spin shortly.

Generated at Tue Oct 17 20:53:59 CDT 2017 using JIRA 4.4#649-r158309.