.getGeneratedKeys support about clojure.jdbc HOT 9 CLOSED

I haven't implemented it because it is looks inconsistent. The execute api is designed just for side effectfull operations that does not return nothing, and fetch is designed to be used for query like stuff (anything that return a result). The getGeneratedKeys is very convenient but it is inconsistent in terms of operations in execute... and can be properly done using RETURNING * with fetch operation.

The main difference with clojure.java.jdbc, is that clojure.jdbc tries to have concise consistent api. I really like clear path for api usage and I'm not very convinced about the .getGeneratedKeys utility in balance with the api consistency. (e.g I have never used that in my apps).

PS: nice library, thanks for creating it, I have plans to create an adapter for suricatta. ;)

from clojure.jdbc.

I definitely understand the consistency issue (see the HugSQL tests for examples). Support is really quite the mess! I made distinctions in HugSQL between "returning execute" and "insert w/ .getGeneratedKeys" in part to encourage the usage of RETURNING * if the user's database supports it. And, I personally use Postgresql and the RETURNING clause in my own apps.

However, database support for the RETURNING * clause is widely unsupported. I think support for it is only available in Postgresql and Oracle.

When a user actually needs support for getting an auto-generated ID, lack of support for .getGeneratedKeys leaves him/her with no option in clojure.jdbc except having to wrap their insert queries with a secondary query to fetch the last inserted id. Maybe that's a hurdle users are willing to jump over to use clojure.jdbc, but I suspect the inconvenience might hinder some adoption of the library.

Either way, I respect the choice to keep a consistent API and to make users deal with those trade-offs.

from clojure.jdbc.

Hmm, i will consider adding this as completely undocumented stuff, because I understand the utility of that, but I don't like promote the usage of that.

I'll implement it today as I have planed release a new version with already merged some bugfixes. Thanks!

from clojure.jdbc.

Thanks for considering it. No pressure here.

(I didn't add support for .getGeneratedKeys in HugSQL until version 0.4.0 because of my own uncertainty about how to implement it well. Ultimately, I decided to make it available but have good tests and documentation on all of the inconsistencies--leaving the user to choose what was appropriate for his/her database.)

from clojure.jdbc.

@csummers This is something that you will expecting? 77afb73#diff-33815d1d7b25e739b789ed1020d3856dR102

from clojure.jdbc.

It behaves differently from clojure.java.jdbc just because it returns a vector of results instead of one unique result.

from clojure.jdbc.

That looks reasonable to me.

from clojure.jdbc.

Released 0.8.0 with that change and other bug fixes.

from clojure.jdbc.

Great! I'll incorporate support for this into the next release of HugSQL.

Thanks!

from clojure.jdbc.