Fields of trigger conditions can now have their types updated in non-atomic migrations.

Type: bug

@kekekekule I wanted to quickly address the issue at #136 and fix some things in your PR at #136. I thought it would be easiest to get this in another PR and deploy since I'm going to be away for a bit. I made sure you are the author of the commit, so you will get credit in the release. I also added you to the README as a contributor. Thanks for your contributions!

I believe that this individual operation still needs to be atomic, even if it's in a non-atomic migration. It's dangerous to drop a trigger outside of a transaction as it could lead to data loss for django-pghistory users and other use cases where triggers are necessary to be installed for data integrity.

I updated the code to still wrap the individual schema change in a transaction, ensuring that the trigger is dropped and re-created in that transaction. So, if your migration looks like this:

class Migration(migrations.Migration):
    atomic = False

    operations = [
        migrations.AlterField(), 
        migrations.AlterField(),
    ]

The separate alter statements won't be wrapped in a transaction. However, an individual alter statement may be temporarily wrapped in a transaction so that the trigger may be able to be safely dropped and re-created while the field is being altered.

I hope that makes sense. I made a failing test case first similar to the one you made, and I just used the normal transaction.atomic. I was incorrectly using a self.atomic utility in the schema editor.

If for any reason this doesn't address your use case, please let me know. I'm happy to revisit it. For now I plan to deploy this as the fix