Add test coverage for passing optimistic lock version as string #8533
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As discussed in doctrine#8527, when using optimistic locking with integer version columns, Doctrine has always supported passing the lock version as a string. For example when passing in a version received in POST / GET. Technically speaking this does not comply with the docs and phdoc (which show the app explicitly casting to int before passing). Nonetheless the maintainers decided it should continue to be valid for now and reinstated the old soft-equals logic with doctrine#8531. This modified test just avoids accidental changes in future.
greg0ire
approved these changes
Mar 11, 2021
SenseException
approved these changes
Mar 11, 2021
|
Thanks @acoulton ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As suggested by @greg0ire I have updated the tests to cover the current behaviour of passing a string
versionargument for optimistic locking.Since #8527 was only-sort-of-a-bug and this is just a simple variation of how
->lockis already tested, I thought it made sense to modify the existing tests to cover this case rather than the overhead of a whole separate test case. Particularly since I guess this will probably change again in a future release, and the goal is just to avoid that happening accidentally in the meantime.If you'd prefer to have a standalone GH8527 ticket test instead I can happily do that, just let me know.