JDBC API has DatabaseMetaData to check for features of the database. Since JDBC3 supportsGetGeneratedKeys is available.
Attention: sqlite-jdbc reports false, but supports it - I'll file a bug on this for sqlite-jdbc
added old hsqldb to test against (jdbc2 driver)
initial setup for tests against Sybase SQL Anywhere
check if jdbc driver supports getGeneratedKeys
added doc strings, cleanup
cleanup, remove references to sql anywhere
removed ignored files
added missing new-line
Merge branch 'generated-keys' of https://github.com/andeee/clojureql …
sorry the amount of commits, just trying to get started with git
Filed bug for sqlite-jdbc: http://code.google.com/p/sqlite-jdbc/issues/detail?id=10
added missing newline
Thanks for the pull request. I have to ask you to clarify and change a few things, before commiting this.
Splitting things up into multiple commits is a good thing. Especially good: first commiting the test cases, then the solution. Makes verifying that much easier. OTOH multiple commits are less than helpful, if you are introducing changes and reverting (some of) them a few commits later.
Could you please clean up the commits? If nothing else, you can do that by creating a new branch with its HEAD at the latest master commit. Then add (possibly failing) test cases, commit. Then commit the fix. If you have an erroneous commit, roll it back with git reset. Don't git revert, unless the change is already released.
You can leave in the test cases against an embedded database, like SA. More databases to run the test cases against, w/o config overhead == good.
Can you clarify, which advantage your approach has, above the currently implemented heuristic?
Is performance better? Does it handle some corner cases better?
If so why and which, respectively?
Thank you for your comments and advice.
I'll try to clarify my intent:
I'll now cleanup the commits and make another pull request.
If you have further questions, please ask.
Great! As far as I have understood, SQL Anywhere is embedded and thus can be used in the test suite w/o any external config. If so, please add it and add test cases, highlighting the wrong behavior. Please also double check, that there are test cases in place for everything that might be affected by your patch (to a reasonable extent, it will be audited anyway).
The latest problems we had in that area (of auto-generated keys), was with newer MySQL drivers. They would throw, if you didn't fetch the generated keys after a query.
Whereas the Postgres Driver would throw, when trying to get generated keys in batch mode.
I implemented a workaround, by only getting generated keys when not in batch mode, as per 257a5e0
You might want to check how your work interacts with that behavior.
Thanks for your help!
Thanks for your further info!
SQL Anywhere is not as embedded as for example derby or hsqldb. Therefore one must download the Developer Editon from Sybase, create the database and deploy the jdbc driver to a local maven repo since it's not available on maven central.
Should I add it to the test cases anyway?
In this case, please not.
If you can easily reproduce it with another db, go ahead, otherwise just make sure it doesn't break anything.
cleaned up commits in #108