if one modifies a schema created with the online editor, does PonyORM perform the required ALTER TABLE statements to upgrade the schema?
At this moment, PonyORM online editor doesn't perform migrations when schema is modified. You need to upgrade schema manually.
You can try to use migration tool from orm-migrations branch. It is not officially released yet. You can copy model definitions from online editor, save them in some models.py file in you project, and use migration tool to create migration. For simple migrations, like, adding attribute or relationship, it should work.
Related
Running typeorm migrations always creates the migrations and typeorm_metadata table. These tables keep track of migrations done for the particular schema. But, I'd like to execute some ddl commands with this migration facility. Is there a way to not generate them for a migration ?
Doesn't seem to be a logical way to do that, but, the way I got around this is by using the migrationsTableName, I changed it dynamically everytime using a word generator, so the net effect would be as if there was no migrations metadata at all. ;-)
I want to do code first development on an existing SQL Server Database. I have used the Scaffold-DbContext command to generate the entities that I want into the tables I want. That's great. But, there were previously code first migrations done to this database. So I deleted the __EFMigrationsHistory table in the SQL Database. Now I want to start doing migrations. Unfortunately, when I run Add-Migration, it generates migration code to generate all of the tables again. I don't understand how I am supposed to tell it that these tables already exist. When I am reverse engineering, how do I generate the migration of the stuff it's scaffolding for me in the existing database?
Code First Migrations uses a snapshot of the model stored in the most recent migration to detect changes to the model (you can find detailed information about this in Code First Migrations in Team Environments).
Source here.
Run Add-Migration InitialCreate –IgnoreChanges to create the initial migration from an existing database. Then update-database to simply add the migration to the _EFMigrationsHistory table.
After that, you are good to go brother.
I am using EF 6 code first. As part of the code-based migration, I would like to rename the existing database after applying all the pending migrations. Can this be done?
I don't think this would be (easily?) possible (without causing errors)
If you rename the database during the migration it wont be able to write the migration out to the migrationhistory table as the connection string will still be pointing to the old database.
Perhaps a better option would be to build something into the system to rename the database and adjust the required configuration outside of EF entirely.
My schema has evolved over many iterations. I have a set of migrations taking the schema from an empty db to one with dozens of tables and scores of columns.
Along the way there have been several additions of tables, columns and constraints, sometimes followed (in light of experience or new knowledge or changes in the spec) by removal or alterations. Sometimes a table or column name has been re-used or re-purposed.
Now, EF migrations seems perfectly able to run through the sequence creating, altering, dropping, creating again, altering, etc., to get to the latest schema, but it feels wrong. In an extreme case there might be dozens of migrations creating tables followed by dozens more dropping tables until the final schema might be one or two tables (unlikely, I know). An option to go from scratch to just those final tables would feel right.
In my Ruby days with ActiveRecord migrations there was an option to build only the final schema, without stepping through and possibly undoing or redoing work along the way. Of course this meant keeping a complete DDL version of the schema up to date after each migration, but somehow it felt more elegant.
Has anyone done anything similar with Entity Framework?
You might like to try deleting the __MigrationHistory table from your database, removing the Migrations folder (backing up your Configuration.cs file), and then enabling migrations again.
Then start here for PM commands to build scripts
Generate full SQL script from EF 5 Code First Migrations
from code, there is an option on the ObjectContext not directly on DbContext
string script = (context as IObjectContextAdapter).ObjectContext.CreateDatabaseScript();
Of course Automated Migrations would work if you dont need to see the magic and have altered the generated scripts.
Database.SetInitializer(new MigrateDatabaseToLatestVersion<YourDbContext,
YourMigrationConfiguration>()
Context.Database.Initialize(true);
And if it is an EmptyDb Schema, EF will do that for free.
Context.Database.Initialize(true);
I've started looking into Entity Framework migrations on 4.3.1. Have a few questions:
What's preferred during development? Why should I not just drop and recreate my
database always and then reseed. If I use code first migrations, can
I choose to seed my db initially and then add a seed method to each
migration to only add in new data? If i use automatic migrations, is
it possible to do something similar? i.e. seed initially and then
seed as required?
What is the benefit of using migrations during development? I only
actually need migrations when moving to production. So, I need to
create my initial script and then scripts for each migration, so
would it be possible to only use migrations once i want to move to
production and at that point create an initial script and maintain a
migration history from that point onwards?
Well, in our case, we started to use Migrations because in our company, devs don't have the necessary rights to create a DB, which lead to the amusing scenario where I dropped the DB a couple of times and had to ask the db admin to recreate it each time...
In my opinion, it seems easier to incrementally grow your DB, rather than having to recreate it each time. If I were to have to drop and recreate our DB every time a property is added, deleted or changed, I'd never see the end of it.
I've not yet seen a possibility for incremental seeds, unless perhaps if you create manual migration files.
Migrations has the possibility to go to a specific version (either forwards or backwards) and it is possible to generate an SQL script from a migration.
So basically, you don't have to create a migration SQL script by hand anymore, you can get Migrations to do it for you.