Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate InsertStatement.generatedKey #424

Closed
spand opened this issue Nov 7, 2018 · 2 comments
Closed

Deprecate InsertStatement.generatedKey #424

spand opened this issue Nov 7, 2018 · 2 comments
Assignees

Comments

@spand
Copy link
Contributor

spand commented Nov 7, 2018

generatedKey is a bad api. It returns a number for an implicit column. This is bad as it effectively forces one to duplicate the column type (ie. doing a generatedKey as Int or generatedKey!!.toInt()) and which column is autoincrement at each usage (ie. you probably need to use the number in another query where you then embed the assumption of which column the generated key came from).

There is already a better way which is the InsertStatement.get(column) which preserves the type and makes it explicit at each usage which column the value was expected to appear from.

There was a brief talk about this on slack, but I create an issue here for added visibility:

Johannes Jensen [Yesterday at 11:35 AM]
Looking at `InsertStatement.generatedKey`. Is there any particular usecase that isnt better handled by `get()` ?
With `get()` you get the correct type, while with `generatedKey` you need to `toInt()` it or similar. Asking as I would prefer to see it removed since I see some bad usages of it in our codebase. (edited)

2 replies
Andrey Tarashevskiy [21 hours ago]
I think that it's rather rare when you have to ask `generatedKey` in your code.
At first, if you use `IdTable.insertAndGetId` then you'll receive id value of proper type.
So I agree that `generatedKey` looks like a legacy and could be hidden from a public scope. But (as you mentioned) many people already use that field and it may be too painful to just to remove the field but we can start with depreciation.

Johannes Jensen [21 hours ago]
Good to hear you agree. Deprecation seems like a good first step.
@Tapac Tapac self-assigned this Nov 7, 2018
@Tapac Tapac closed this as completed Nov 17, 2018
@xJoeWoo
Copy link
Contributor

xJoeWoo commented Nov 24, 2018

Will BatchInsertStatement.generatedKey still accessible? generatedKey seems the only way to get multiple generated results from batch statement, due to InsertStatement.resultedValues is protected.

Also, "upsert" needs this property: #167 (comment)

@Tapac
Copy link
Contributor

Tapac commented Nov 27, 2018

@xJoeWoo, I plan to replace generateKey with some kind of result: List<ResultRow>, then it will be able to write: result.get(idCol) to obtain key in upsert sample.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants