Fix inconsistent behaviour across adapters with read types and "create" command #432
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
Similarily to what Update command do, use `dataset` to load the tuple after `insert` in Create command. This way it loads "raw" data, without applying read types yet. So when tuples are passed into `finalize` hook, it can properly apply these read types.
|
These CI failures look weird. Did my changes cause them? |
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.
During the investigation for #423 I discovered that for SQLite and MySQL (or basically for everything aside from PostgreSQL) the read types are applied twice. This works well if the read type allows it, but if it does not, it fails for these adapters, making behaviour between adapter inconsistent.
The solution here is to use
relation.dataset.whereinstead ofrelation.wherein default implementation ofinsertmethod ofCreatecommand.relation.wherealready applies the read types on materialization, whilerelation.dataset.wheredoes not. This is also consistent with howUpdatecommand behaves.With that in place, we always call
finalizeon "raw" data from the database, avoiding double application of a read type.The PR consists of two commits. First one just adds tests replicating the problem. The second one just changes the code.