Fork me on GitHub

That's just what the JDBC driver returns @souenzzo -- It's why's test suite has to have all sorts of DB-specific logic to extract keys / know which DBs return keys etc.


SQL is relatively portable but a lot of JDBC behavior isn't, unfortunately.


So this "issue/limitation/behavior" is about com.h2database/h2, not about org.clojure/java.jdbc?


@souenzzo just returns whatever the driver gives it.


JDBC drivers vary a lot between databases. Of the databases I test against with, PostgreSQL is the only one that returns the entire row. Most of them return a result set containing just the generated key (although each database uses a different name -- for example, MySQL uses generated_key, SQLite uses last_insert_rowid()


Writing portable DB-access code is a real challenge.


@souenzzo are you using h2 because you need something local to test postgres with? Or are you actually using both databases in your non-test codebase?


if it's just for testing purposes, we've used with great success for downloading/creating/starting a local postgres specifically for your test run. We used to use h2 for testing, but the differences between h2 and postgres were too large and made it so we were testing things that had little resemblance to production


I will look on this otj. It's just a develop tool; Real tests on CI will use postgres. (`A little lazy to run local postgres`)


@souenzzo If you use Docker, running PostgreSQL locally is trivial. It's how I test against PostgreSQL.


@seancorfield we actually recently switched to a dockerified version of the pg-embedded that's still efficient in spinning new clean DB's. I have Friday afternoons to work solely on open source projects at Yummly, and that is the next project I plan on open sourcing, since it has less...tangential problems then the pg-embedded one