Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
When getGeneratedKeys is not supported, non-multi statement execution result treated as seqable
Description
This commit introduced a way to apply row-fn to result of statements that return autogenerated keys. It also introduced a bug in case getGeneratedKeys is not supported. The code in db-do-execute-prepared-return-keys, in the exception handler, runs:
(result-set-fn (map row-fn counts))
But the counts value can be non-seqable (an int), based on:
It seems that this code path is used from insert!, while in execute!, this can be avoided by not passing :return-keys. multi-insert-helper seems to use db-do-prepared-return-keys unconditionally.
I guess in this case, when the database does not have support, providing :return-keys makes no sense (least so in this implicit manner).
Environment
Redshift (but should apply to any database without getGeneratedKeys support), java.jdbc 0.7.8 (also in current master).
Activity
Sean Corfield
February 21, 2019 at 6:35 PM
Release 0.7.9 is heading to Maven Central!
Sean Corfield
January 8, 2019 at 10:16 PM
Then thank you to Juha too! Much appreciated!
Kimmo Koskinen
January 8, 2019 at 2:21 PM
Thank you, that was fast!
Credits for the catch belong to my colleague, Juha Niiranen, I merely did some grunt work on writing the Jira issue
Sean Corfield
January 7, 2019 at 9:34 PM
Will be in 0.7.9
Sean Corfield
January 7, 2019 at 9:27 PM
Good catch! I'm going to address this by wrapping that .executeUpdate call in vector, as is done in other places to ensure that counts is seqable.
This commit introduced a way to apply row-fn to result of statements that return autogenerated keys. It also introduced a bug in case getGeneratedKeys is not supported. The code in db-do-execute-prepared-return-keys, in the exception handler, runs:
(result-set-fn (map row-fn counts))
But the counts value can be non-seqable (an int), based on:
(let [counts (if multi? (.executeBatch stmt) (.executeUpdate stmt))]
It seems that this code path is used from insert!, while in execute!, this can be avoided by not passing :return-keys. multi-insert-helper seems to use db-do-prepared-return-keys unconditionally.
I guess in this case, when the database does not have support, providing :return-keys makes no sense (least so in this implicit manner).