A mechanism for reading specialized types from result sets could be useful
Description
Environment
Attachments
Activity
gfredericksMay 26, 2013 at 10:27 PM
Sounds good to me.
Sean CorfieldMay 22, 2013 at 3:40 AM
:row-fn is intended for whole-row transformations - it is lazily mapped over the result set - so it's really meant for post-processing your data in a general sense while the connection is open. The protocol-based column reader is intended to transform specific types of data, independent of any application semantics (e.g., Oracle returns an oracle.sql.TIMESTAMP which can be automatically transformed into a java.sql.Timestamp or Date or whatever).
And :result-set-fn is intended for whole-result-set transformation, just prior to returning the result set.
gfredericksMay 22, 2013 at 1:53 AM
That use case could be served by :row-fn, right? You just like that it's easier? I don't mind it if others still find it valuable, I just wanted to make sure we didn't accidentally cement redundant features.
Sean CorfieldMay 22, 2013 at 1:19 AM
This turns out to be a very useful hook for certain database types. I used it to solve an issue with Oracle, to enable users to automatically convert Oracle-specific datatypes to regular values, in JDBC-57. So, thank you... even if you think it isn't necessary now!
gfredericksMay 15, 2013 at 3:52 PM
I'm thinking this feature is no longer necessary due to the :row-fn option – since the only motivation in the first place was to have the opportunity to transform a result before the connection closes.
There would still be no easy way to do it from Korma, but that's Korma's fault. So maybe we should remove this before 0.3.0 is released?
Details
Assignee
Sean CorfieldSean CorfieldReporter
gfredericksgfredericksPriority
Major
Details
Details
Assignee
Reporter
Priority
Major
I had this idea when trying to adapt Korma to use with postgres tables with columns of array types. I had some success using Korma's transform functions to convert the java.sql.Array objects into a seq on the way out, but recent changes to Korma seem to indicate that the transform functions are not guaranteed to run before the connection is closed. This interferes with efforts to read the arrays, which I think can be their own result sets.
Presumably korma could be changed to support reading the arrays on the way out, but maybe being able to customize the read behavior within c.j.jdbc would be simpler.
The first idea I've had toward this end is to create a protocol with a single function that objects being read out of the resultset get passed through. It would default to the identity function, but users could e.g. extend it to java.sql.Array. I don't know if there are significant performance implications for an extra function call for each value coming out of the database.
I'll have a patch in this vein attached shortly.