Last post May 06, 2020 11:45 PM by Madog
May 04, 2020 11:59 PM|Madog|LINK
I plan to add another independent application to the portal that will use the same VS project but points to a completely different database, albeit on the same server.
I plan to create a new ADO.NET Entity Data Model(Code First from Existing Database) and DbContext that points to the new application's database.
This is an existing database that is also used by an old Web Forms application I support, in a completely different website/server and VS solution.
I suddenly realized that any design changes I make on SQL Server to the existing database, inline with the Web Forms website requests, will cause trouble with Code First migrations, as it will detect changes not inline with the known CF Migrations schema.
This could turn into a nightmare to support.
Any ideas to get around this.
Thanks for considering
May 05, 2020 08:25 AM|Sean Fang|LINK
I discussed this problem with some other developers and felt that it would be unsafe to have this design.
Although you could avoid to delete the columns and keep the database being capable of running by communication between two different teams/developers, it requires a higher cost on cooperation and testing.
If the two applications are completely independent of one another in the same database, it won't be a problem since EF6 migrations supports migration of
multiple models in this condition.
If you check the __MigrationHistory table in the Code First database, you will find that there is a column called "ContextKey" which is used to identify the Migration from different context.
More details, you could refer to this: EF6 Code First Migrations for Multiple Models
If the two applications are going to share one or more than one tables, you should be aware of troubles of
I suggest you only allow the original application to be able to
change the schema and DbContext of the
existing database and then expose some
data api for another application. That way, the new application is
only allowed to access the data in the same database. If the new application has needs to
modify the schema/DbContext, the new application's team should communicate with
the original application's team, which will reduce the
communication cost compared to the current design.
If you will have more applications facing the same problem, you might need to consider create
a webapi project for data accessing, which would isolate the data access from other applications.
Hope this can help you.
May 05, 2020 01:10 PM|DA924|LINK
Maybe, you need to stop doing migrations. EF or any ORM is not a DBA tool traditionally anyway.
May 06, 2020 11:42 PM|Madog|LINK
Thankyou Sean Fang for taking the time to so thoroughly consider the issue.
I am in fact the programmer supporting both these projects, so communication between teams is not a problem, as I quite often talk to myself.
The old application is a Webform's app with no concept of DbContext etc.
If I make a change to a shared table thru ADO.Net datasets in the Webforms app, I will indeed run into issues with the Code First migrations in the new app.
In any case, I have decided to bail on the whole idea of sharing tables and databases. The whole concept adds unnecessary complexity and is not simple to maintain and keep in synch.
I will read the article you suggested as every bit of information helps in unravelling the mystery of EF and Migrations.
May 06, 2020 11:45 PM|Madog|LINK
I'm hearing you. Every time I make a change to the model, I just pray migrations gets it right when promoting to Production, especially since there is 'magic' involved that I can't control. So far, it's worked out.