I need to use db-migrate to add an index to a Postgres database with CREATE INDEX CONCURRENTLY. However, db-migrate wraps all migrations in a transaction by default, and trying to create a concurrent index inside a transaction results in this error code:
CREATE INDEX CONCURRENTLY cannot run inside a transaction block
I can't find any way to disable transactions as part of the db-migrate options, either CLI options or (preferably) as a configuration directive on the migration itself. Any idea if this can be accomplished?
It turns out that this can be solved on the command line by using --non-transactional. Reading the source, I can see that this sets an internal flag called notransactions, but it's not clear to me whether this can be set as part of the migration configuration or must be passed on the command line.
I kept getting the errors even when running with --non-transactional flag.
The solution for me was to run with --non-transactional AND have each CREATE INDEX CONCURRENTLY statement in its own separate migration file. It turns out you can't have more than one of it in the same file (same transaction block).
Related
We are experiencing an issue on v2011, where using the admin aspect with the updatesystem command, does not actaully do an updatesystem. By that i mean, it does not perform any typesystem updates or impex etc. where have also tried the command with passing a config file but still the same result. Also, if the completes it shuts down the container and just starts it back up again.
Tried basing the typeSystem only argument, and also a passing a config json file. Check DB SystemINit table to ensure it was not locked
I'm using EXEC CICS SYNCPOINT and EXEC CICS SYNCPOINT ROLLBACK to commit/backout updates to VSAM and DB2 tables when abend happens. However, only updates to DB2 tables are backed out not on VSAM. Am I missing something? CICS parameter RLS is set to RLS=NO.
It will depend on the type of files that you are using. If you are using RLS files then you have to define the files correctly using idcams using the LOG parameter see:
https://www.ibm.com/docs/en/zos/2.2.0?topic=cics-recoverable-nonrecoverable-data-sets
If you are using non-RLS files then you need to set the attributes correctly on your FILE definition.
See the following page within the CICS documentation that describes about file recovery:
https://www.ibm.com/docs/en/cics-ts/5.6?topic=resources-recovery-files
I have an existing app which uses SQLAlchemy for DB access. It works well.
Now I want to introduce DB migrations, and I read alembic is the recommended way. Basically I want to start with the "current DB state" (not empty DB!) as revision 0, and then track further revisions going forward.
So I installed alembic (version 1.7.3) and put
from my_project.db_tables import Base
target_metadata = Base.metadata
into my env.py. The Base is just standard SQLAlchemy Base = sqlalchemy.ext.declarative.declarative_base() within my project (again, which works fine).
Then I ran alembic revision --autogenerate -m "revision0", expecting to see an upgrade() method that gets me to the current DB state from an empty DB. Or maybe an empty upgrade(), since it's the first revision, I don't know.
Instead, the upgrade() method is full of op.drop_index and op.drop_table calls, while downgrade() is all op.create_index and op.create_table. Basically the opposite of what I expected.
Any idea what's wrong?
What's the recommended way to "initialize" migrations from an existing DB state?
OK, I figured it out.
The existing production DB has lots of stuff that alembic revision --autogenerate is not picking up on. That's why its generated migration scripts are full of op.drops in upgrade(), and op.creates in downgrade().
So I'll have to manually clean up the generated scripts every time. Or automate this cleanup Python script cleanup somehow programmatically, outside of Alembic.
I want to run multiple alter-column commands at once (to save some time).
For example, I have these 2 commands:
.alter column e53b2c81_eb5c_45e4_9e5e_333332211111.name policy encoding type='identifier'
.alter column e53b2c81_eb5c_45e4_9e5e_333332211111.doc policy encoding type='bigobject'
And running them separately works fine. but I want to invoke them together. So I tried something like:
.alter column e53b2c81_eb5c_45e4_9e5e_333332211111.name policy encoding type='identifier';
.alter column e53b2c81_eb5c_45e4_9e5e_333332211111.doc policy encoding type='bigobject';
But it didn't work.
Is there any way I can run them both together?
(Eventually, I want to avoid running this query for 1000+ tables for different fields. I much rather performing this task at once to avoid so many requests. I'll be running these commands through the Golang SDK).
You could include all commands in a script, and use the .execute database script command to have them run by the service one after the other.
Please note that this does not run all commands in the script in a single transaction - commands are executed sequentially, in the order they appear in the input script.
I have an app configured
config :my_app,
ecto_repos: [MyApp.Repo, MyApp.LegacyRepo]
MyApp.Repo's migrations are managed by Ecto.
MyApp.LegacyRepo migrations are handled by Rails and error out on mix ecto.migrate
Is there a way to specify "I have two repos, but please ignore the second for migrations"?
Another option is to change your config.exs. Change it to...
config :my_app, ecto_repos: [MyApp.Repo]
According to the ecto.migrate documentation...
The repositories to migrate are the ones specified under the
:ecto_repos option in the current app configuration. However, if the
-r option is given, it replaces the :ecto_repos config.
Not having a MyApp.LegacyRepo in ecto_repos doesn't prevent reads or writes or anything else you'd expect. It just configures the migration task.
You can pass a repo into mix ecto.migrate like this
mix ecto.migrate -r MyApp.Repo
You can update test/test_helper.ex in a phoenix app to only run one repo migrations like this
Mix.Task.run "ecto.migrate", ["-r", "MyApp.Repo", "--quiet"]