What''s the politic for a database upgrade with LINQ to EF ?
Here's the problem :
An application v1 using a database with its EF mapping is installed to the customer.
The new release v2 of the application must be installed over v1. It has mapping modifications and the database structure has changed a little bit. Of course, we want to keep the data, this is just an upgrade of the application and the database.
How should the application handle that so that the upgrade can be done automatically ?
I mean, this is a typical problem that is usually solved by the software by upgrading the database structure at launch time.
If the application is totally abstracted from the DB structure (i like that idea), how should we upgrade the base ?
(sorry for my bad english, i'm french ;o) )
[809 byte] By [
sheseh] at [2008-1-8]
In order to support this kind of scenario, you would need to keep two models in your application. One model for the old structure and one model for the new structure. Presumably you would have some way to detect at launch that the database needs upgraded, and if you make that detection, then you would read data with a context built around the old model, copy the items into new items built for the new structure and then save them on the new context.
The one gotcha is that the EF does not provide any mechanism for actually modifying the database--for that you would need to write direct SQL to your backend, and then the technique I just described could be used to migrate the data. Of course, this whole process might need to be considerably more sophisticated if you have a LOT of data and need to modify it in place. For something like that I think you would be stuck doing the whole thing with hand-written SQL against your backend. In a future release of the EF where we have DML and maybe even DDL support, then you could do the whole thing directly in the entity framework, but that's certainly still a ways a way.
I did do a data migration like I described in the first paragraph above with an app of my own recently. I had written the app a bit more than a year ago with a very early version of the entity framework, and when I upgraded the app to a more recent version of the framework I found that there were so many new features that I wanted to take advantage of that it was a complete redesign of the database. So I created a new DB on the same server which had the schema that I wanted to use going forward, and then I generated code from both the old model and the new model. I added methods in the partial class for each entity on my old model that would create an instance of the corresponding new type and copy the data from the old entity to the new entity. Then I could write a small migration app that would query the old DB, iterate over each entity, create the new instance, add it to the new model and then save.
- Danny
I guess you mean something of this kind :
Have one mapping for each database structure version. Having the corresponding class to each entity and having a conversion method for each entity class (as partial class) that converts to the next upper version. Then we would iterate through each entity to convert data.
Ex:
V2 : this is the actual version of the class we want upgrade to
| namespace Entity { Class Person { public string FirstName; public string LastName; public int Age; }; Class Adult : Person { }; Class Child : Person; { }; } |
V1:
The existing Person version, that we want to upgrade from
Auto generated class, from the mapping :
| Namespace Entity_v1 { Class Person: { public string Name; public int Age; } } |
Partial class added manually and providing conversion:
| // We also need to know the current version Entity namespace Using Entity; Namespace Entity_v1 { // Completes the auto-generated class Person Partial class Person { public static void Upgrade() { Entity.Person new_p; foreach(Person_v1 p in Entity_v1.Person) { if(p.Age >= 18) { new_p = new Adult(); } else { new_p = new Child(); } new_p.LastName = p.Name; new_p.FirstName = “”; Entity.Person.Add(p); } Entity.Person.Save(); // Data is exported to the new database } } } |
There must also be an Entity mapping for each version.
NB : Is not code, it's "pseudo code" ;o)
