Closed chopmo closed 6 years ago
Thanks for the PR. I'm inclined to merge it, but give me a little time to think about whether this is the best way to achieve it.
As for tests, we can at least check to see if migrations work regardless of whether or not :transaction?
is true or not. Presumably you've also manually tested to see if it works in Postgres?
Sure, thanks for considering.
I've added a few test cases to at least ensure that existing functionality does not break.
And yes, I did manually test this with Postgres 9.5.10.
hi @weavejester,
when does this feature release?
Apologies for letting this lie dorment. I think this is fine for merging, it just needs the commit messages to be updated as per the contributing guidelines.
Should there be separate settings for disabling transactions for up and down?
Maybe:
:transactions :up
:transactions :down
:transactions :both ;; (or true)
@weavejester No problem, and apologies for not checking the contribution guidelines
@danielcompton Yes, I think that makes sense!
I'll see when I can find time to finish this up.
@weavejester No problem, and apologies for not checking the contribution guidelines
Your PR predates the contributing guidelines, so that's fine :)
@weavejester Haha, I guess that is a good excuse then :) I have now changed the PR to contain a single commit, adding support for applying transactions in only one direction. I've also tried my best to follow the guidelines for the new commit message.
@danielcompton Thanks for the idea - your thoughts are very welcome too of course.
Thanks! I think the example in the commit message can be removed, as the previous paragraphs cover the change adequately. Also the triple backtick isn't necessary in this case, as a commit message is plaintext, rather than markdown.
Could you also ensure that the lines you added don't exceed 80 characters in length?
Sure! I'm not sure how you prefer the code in the defrecord
to be formatted, but I gave it a shot.
Thanks, sorry this took so long to get merged.
No problem, thanks for merging!
This change allows a migration to declare that it should not be run in a transaction, or that a transaction should only be applied in one direction.
Only supported when defining migrations in EDN. Example:
My motivation for suggesting this feature is that I need to add an index with the
CONCURRENTLY
option as in the example above. This currently fails with the errorPSQLException: ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block
.This is also an attempt to address #119.
I was unsure about how to include tests for this, but given a hint or two I'd obviously be happy to give it a try.
EDIT: At the suggestion of @danielcompton , added suport for only applying transactions in one direction. The
transaction?
option has been renamed totransactions
and now accepts the values:up
,:down
,:both
ortrue
(any other value, likefalse
, turns off transactions in both directions).