Improve transaction usage in beam-automigrate #48
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
The top-level module was a mix of code for munging and outputting information about migrations, and code that actually executed migrations. The former has been split out into Database.Beam.AutoMigrate.Eval, and the latter into Database.Beam.Automigrate.Unsafe. The top-level module now exports migration executions that wrap everything in a transaction, and the Unsafe module exports them without the transaction wrapper: that's why they're extremely unsafe.
madeline-os
force-pushed
the
unwrapped-migration
branch
from
6a15bb7 to
89ebf67
Compare
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.
[x] Plan migration in the same transaction as the attempted execution
[x] Expose attempted migration without transaction so user can embed it in their own
[] unmangle the haddocks
[] make the README literate example not rely on unsafe stuff
At first, all I wanted to do was make sure that the main entry points were obviously guarded by a transaction, and expose unsafe entry points for the user to incorporate into their own larger migration logic (which should definitely be in a transaction). However, the top-level module was very large and sprawling, and I had to tease apart the functionality that didn't interact with the DB, and the part that did, so that I could make sure I didn't miss anything. So it goes.