What is the best practice with dealing with EF migrations in a team environment? How can you ensure that people branching and merging code actually commit their migrations in correct sequence? How would you go about making sure the migrations are applied in the order they were merged into the release branch? Is that something team members have to deal with manually or can you leverage your build server to do automatically?
Ok, I was able to find an article on how to deal with merging migrations properly: https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Related
As a project grows, migrations (both makemigrations and migrate) take longer and longer delaying quite a lot every deployment.
Django let's you to squash them so you don't have a long list of migration files but still, the migrations take the same amount of time.
Then I tried the following:
Remove all the migration files in my app
Clean the django_migrations table in the DB
Run makemigrations (to create the 0001_initial for my app)
Run migrate --fake (to populate to django_migrations table)
Now the new migrations are really fast at the expense of losing the migration history.
So my question is, considering that this could be like a v1.0, and it is a standalone project which any other project depends on, What are the risks of doing this?
I have the feeling that it is something that should not be done, since I could't find any specific Django command to do it. South has a reset, but now django migrations only has the squash...
As long as all your installations was up to date when you deleted the migrations, there is no harm to delete old migrations. The single drawback is you can't go back in the database historic state easily once you deleted them, but except in case of old backups file, you should not have any use of it.
As I pointed out, just make sure everyone using your project is up to date before (or give them indications like the commit before the deletion so they can do the migrations before upgrading to HEAD if you are using a source version control).
If you are developping a third party app, it will make the installation more complicate (dealing with the --fake argument whether you are upgrading or installing...) but this is not your case.
We are using code first migrations to keep our database and model in sync. At the moment we have the version number as name for the migration which clearly doesn't work out.
The problem is that multiple migrations with the same name where created by different developers independent of each other for their local database. This led to some weird behavior as the IMigrationMetadata.Id was different because of the time stamp but the classes are partial with the same name.
What is the way to go to call these migrations? The examples are always ridiculously oversimplified: e.g. adding a property Readers result in migration AddReaders.
Or should the migrations be broken down to these little changes? Instead of having accumulate all the changes into one big migration. What if there are dependencies?
Yes, I think the best way is to break down changes to small units, with descriptive names. As with git, where you should commit often, with migrations you should migrate often. Not necessarily property by property, but containing a logical unit of work.
Like if you need to add two tables for some feature, add those two tables in one migration. Avoid making big migrations where your work for days changing models before creating a migration. Time is essential with avoiding conflicts.
If there are dependencies, one migration should contain related changes, so if another developer applies the migration, the application still works.
When a developer makes a migration, it should be immediately committed and synced (shared with other devs, in case you are not using git).
When you work with small units of change, merging and resolving conflicts becomes much easier.
I have been struggling with the same problem and trying out different solutions. What we have come up with so far is to have all the developers exclude the migrations from the check in process and then have one designated developer do the "release migration" that includes the changes from all the others working on the project.
In a number of team projects I've worked on over the past year, we have chosen the Telerik OpenAccess ORM as the tool to manage our database model. We also use TFS as our version control software
I've ran into a number of difficulties using the Telerik product (which I'll save for another day), but one of the biggest issues is when multiple team members attempt to work on the model simultaneously, and try to commit their changes to TFS. The models generated by Telerik are difficult to merge and any conflicts will, more often than not, lead to time lost fixing the entity model. The only practical way to avoid these difficulties seems to be to implement a "relay" system, where only one person at a time can work with the model; something that isn't practical in a team development environment.
Has anyone found a way to use the two tools harmoniously?
This will always be an issue when working with similar models, even the model used by the Entity Framework.
You could always switch to Code Only mappings though. Then all of the mapping for your project will be simple, merge-able code files. link
I'm working on a major update of an iOS application. Let's say that we have two branches, develop contains what's currently on the App Store and feature/new_version the one with the major update.
feature/new_version has a lot of model changes, so there's a new model version there that adds/removes entities, properties, etc. On the other hand, we had a couple of minor improvements and bugfixes in develop, that caused the creation of new model versions as well (these were updates submitted to the App Store too).
Now I'm stuck with two branches with very different data models. The question is: If I add the "missing" properties to the feature/new_version model, will core data be intelligent enough to do an automatic lightweight migration when I submit the major update to the App Store? Or should I download the data model used in develop and create a new model version in feature/new_version based on that one and re-add / remove all the changes since I first created the branch?
Whether automatic lightweight migration works depends on the nature of the changes from the old model to the new one. In your case, the differences between the currently released version to the one in your new_version branch.
If the changes are just adding new attributes, no problem, this is the scenario that automatic lightweight migration was designed for. If they're more complex, you're more likely to need some alternate migration scheme. You didn't detail the changes, but since you said that the new version "adds/removes entities" automatic migration doesn't sound very likely. Adding in the "missing" properties won't help if there are structural changes to the model. Core Data doesn't mind simple migrations but won't infer a refactoring of the model structure.
How you create the merged model doesn't really matter as long as it contains everything you need. If adding the new properties is all it takes, there's no reason to start over. What matters is that the resulting model is correct, not the steps you took to get it there.
The easiest way to tell whether automatic lightweight migration will work is often to just try it on a debug build and see what happens. Install the currently released version on a device, create some data, and then use Xcode to install the new version. Make sure that NSMigratePersistentStoresAutomaticallyOption and NSInferMappingModelAutomaticallyOption are both YES when adding the persistent store. If it works, great. If not, Core Data provides alternatives for when the model needs more than trivial changes.
I'm about to branch a project that uses EF. I know that there will be a modicum of changes in the trunk, as well as many changes in the branch. I will need to merge in changes from the trunk into the branch from time to time.
I'm not concerned about the straight up C# code that usese EF objects (Linq to Entities) I'm concerned about the entity model itself?
The branching / merging / and concurrent development story for EF entity models is a known sore spot. I think you are just going to have to manually merge the differences in the cases when automerge fails. Alternatively, you could go with the code only approach added in EF 4 and forget about entity models altogether.
You may want to check out this related question if you haven't already:
Entity Framework Merge Nightmare