I am using Flask-Migrate==2.0.0. Its not detecting the changes correctly. Every time I run python manage db migrate it generates a script for all models although they have been added successfully in previous revisions. I have added two new columns to a table, migration revision is supposed to have only those two new columns instead all tables are added to it. Is there anything I am missing?
EDIT 1
Here is whats happening.
I added Flask_Migrate to my project.
python manage db init
python manage db migrate
python manage db upgrade
Flask-Migrate generated tables for models plus alembic_version table with having revision
985efbf37786
After this I made some changes. I added two new columns in one of my table and run the command again
python manage db migrate
It generated new revision
934ba2ddbd44
but instead of adding just only those two new columns, the revision contains script for all tables plus those two new columns. So for instance in my first revision, I have something like this
op.create_table('forex_costs',
sa.Column('code', sa.String(), nullable=False),
sa.Column('country', sa.String(), nullable=False),
sa.Column('rate', sa.Numeric(), nullable=False),
sa.PrimaryKeyConstraint('code', 'country', name='forex_costs_id'),
schema='regis'
)
The second revision also contains exactly the same code. I don't understand why if its already generated.
I googled it a little and my problems looks exactly like this https://github.com/miguelgrinberg/Flask-Migrate/issues/93 but I am not using oracle DB. I am using Postgresql. Also I don't know if it has any effect but I am not creating my tables in Default Public Schema, instead I am creating two new schemas (schema_a and schema_b) as I have a lot of tables(Around 100). So just to arrange them.
EDIT 2
The first problem seems to have resolved by adding
include_schemas=True
in env.py.
Now the new migration is not trying to create already existing tables again but it has some issues with foreign keys. Every time I create a new revision, it tries to remove the already existing foreign keys and then tries to add them. Logs looks like this
INFO [alembic.autogenerate.compare] Detected removed foreign key (post_id)(post_id) on table album_photos
INFO [alembic.autogenerate.compare] Detected removed foreign key (album_id)(album_id) on table album_photos
INFO [alembic.autogenerate.compare] Detected removed foreign key (user_id)(user_id) on table album_photos
INFO [alembic.autogenerate.compare] Detected added foreign key (album_id)(album_id) on table prodcat.album_photos
INFO [alembic.autogenerate.compare] Detected added foreign key (post_id)(post_id) on table prodcat.album_photos
INFO [alembic.autogenerate.compare] Detected added foreign key (user_id)(user_id) on table prodcat.album_photos
I have tried adding name to each Foreign Key constraint but that doesn't have any effect.
Thanks for coming back and providing your feedback after you solved the issue. I had grief with the same issue for 2 hours while using postgres
Btw, I would like to point out that you would have to include the include_schemas option in the block context.configure, like so:
context.configure(connection=connection,
target_metadata=target_metadata,
include_schemas=True,
process_revision_directives=process_revision_directives,
**current_app.extensions['migrate'].configure_args)
Setting search_path to public fixed this issue. I always thought that in addition to setting schema info explicitly on each model, we also need to add those schemas on search_path. I was wrong. Changing postgresql search_path is not necessary once schemas are defined explicitly on each model.
The search path means that reflected foreign key definitions will not
match what you have in your model. This only applies to foreign keys
because that's how Postgresql does it. Read through
http://docs.sqlalchemy.org/en/latest/dialects/postgresql.html#remote-schema-table-introspection-and-postgresql-search-path
for background. - Michael Bayer
Related
I am working on a new application in .Net 5 using EF Core. After creating some entity classes and doing the first few migrations I discovered that I wanted to change the data type of column and make it the key in one of the tables. I was able to do that without issue and the app works just fine with that change - but now if I try to change anything else in that table like add a new column and do a migration I get the following error: "To change the IDENTITY property of a column, the column needs to be dropped and recreated." I have tried even dropping the entire table - but nothing seems to work.
Whenever your migrations get messed up, especially early in a project, just delete the migrations folder, drop the Migration History table and start fresh with a new initial migration.
I have some Hibernate code running against a Postgres 9.5 DB, which looks like roughly like below (anonymized) -
Integer myEntityId = myEntity.getId();
getCurrentSession().evict(myEntity);
myEntity.setId(null);
MyEntity clonedMyEntity = (MyEntity)getCurrentSession().merge(myEntity);
myEntity.setMyBooleanField(false);
getCurrentSession().save(myEntity);
I have an entity myEntity with a large number of fields. I want to create a duplicate of the record with only 1 field value changed. To achieve this, I evict the entity from session, set Primary Key to null, merge it back to session, set the field I want to change, and then save the entity to DB. However, this code (which was working correctly for some time), is not working now. It sees incorrect value for the boolean field I am trying to modify - as a result violating some database constraints. Please help me fix this or suggest a better way to achieve what I am trying.
The error was happening not on adding this record but on add of another record to an audit table, triggered by the addition of this record. A coworker suggested me to use Eclipse Breakpoint view and use the add breakpoint option there and select the ConstraintViolationException class - this helped me to see the error for which trigger was failing and why and accordingly modify the data to suit the database constraint.
I have a solution that has spontaneously started generating the error "Invalid object name 'Item_id'". I have searched for this but all answers seem related to code first issues around pluralization; my project is database first.
The context is that there is a Purchase with a collection of ItemPurchaseLines which are linked to Items. The error occurs when a new purchase is generated, this generates new ItemPurchaseLines and either links them to existing Items or generates new Items. The mapping between ItemPurchaseLines and Items is via a foreign key on Item_Id to Id respectively.
I have regenerated the model from the database and the relationships/column mappings all look good.
Any help, or any further information you need, would be appreciated.
Edit
I have built a LinqToSql alternative and it gives exactly the same error.
OK - I am a complete idiot!
I completely forgot that I added a trigger to the relevant table to update the pl_Items table but instead of using the correct table name I used Item_Id.
So the code from VS was all good it was the SQL Trigger in the back and that was screwing things up!
I am using Entity Framework 5 RC, code first. I am struggling with migrating databases that were created on different versions of code. For example, Database A was created when table FooBar didn't exist. Database B was created after table FooBar was added to my model.
I have a migration written that adds the FooBar table. Is it my responsibility to check in the FooBar migration that the table doesn't exist before calling CreateTable? It seems that is the case since Database B doesn't have an entry for the FooBar migration and will attempt to run it.
At first the MigrationHistory table seemed like it would save me from adding these checks but since new databases won't have entries for migrations added before the database was created, I still need to do the checks myself. Is that the right way to go about it or am I missing something?
To get around an issue I had with adding Stored Procedures, I wrote a TSQL script to create a new table "_PreviousMigrationHistory" - which receives new entries from the "_MigrationHistory" table after my stored procedure scripts have run...
I did add a new column to both tables ( "VersionId", of INT - IDENTITY(1,1) ) which is what I use for comparison within my code.
This way you have the un-updated migration patterns available to you (__PreviousMigrationHistory), even after Code First Migrations have occurred.
Would this help?
**EDIT - sorry, I miss read the question. - Although I would think that new instances of the database would still go through the migration steps, which in turn should add the entries to the __MigrationHistory table?
I'm giving EF Model first a go. I'm using EF 4.1
Pretty much followed this article
I've set PluraliseNewObjects to False on the Model and also in Options->Database Tools ->O/R Designer set Pluralization of names to false.
Neither have any effect - when I generate a new schema from the model the table names are always pluralised - is it possible to disable this?
OK - I've found one way to achieve what I want - but it's a pretty daft route.
Generated db with the plural names (interesting that it only pluralised the tables mapping to types - not the auto-generated linking tables for many to many joins).
Manually renamed the tables in the database
Deleted Model from the project and recreated based on existing database schema (the one I've just renamed).
Model is now correctly mapped to singularly names tables.
I'll wait and see if anyone comes up with a more sensible way of achieving this....
The names of the tables in the generated DDL seem to match the "Entity Set Name" values (different than the "Entity Name"). If you singularize the Entity Set Names, the table names in the DDL are singularized as well.
This will have the possibly undesired effect of singularizing the EntitySet property names in your code, though. Instead of:
myDatabase
.Products
.Where...
.Select...
your code will look like:
myDatabase
.Product
.Where...
.Select...
may or may not be an issue