You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another thought, the generated keys doesn't really have to be a long. They could be any type. I made it Long to be consistent with updateAndReturnGeneratedKey, but it would perhaps be more useful if it took an Row -> T as a param for mapping the generated keys from the resultset.
This (i.e - adding Row -> T) is actually very useful, instead of just receiving the ids
As a matter of fact, it can save an additional roundtrip to the db, just to get the extra columns from that table that we batch-inserted values to.
If this is something that can be done, I'd be happy to join as a reviewer.
The text was updated successfully, but these errors were encountered:
As far as I know, the type resolution depends on how each JDBC driver works. If someone can enhance this library without bringing any breaking changes to existing apps, I am fine to have the change in future versions.
Another thought, the generated keys doesn't really have to be a long. They could be any type. I made it Long to be consistent with
updateAndReturnGeneratedKey
, but it would perhaps be more useful if it took anRow -> T
as a param for mapping the generated keys from the resultset.Originally posted by @magott in #52 (comment)
This (i.e - adding
Row -> T
) is actually very useful, instead of just receiving the idsAs a matter of fact, it can save an additional roundtrip to the db, just to get the extra columns from that table that we batch-inserted values to.
If this is something that can be done, I'd be happy to join as a reviewer.
The text was updated successfully, but these errors were encountered: