Auto Migration, Database Trigger, MultiColumn Primary Key DataAnnotations, AutoColumnOrdering

[hintsofttech]

Dear Sir/Mam,

We are extremely waiting for ....

1. Ef-Core Auto Migration
As it's impossible to use client's resources and run CLI for every Additions/Modifications made to dbcontext models,
we have to auto-migrate those changes to clients pc when dbcontext initialized.

it should auto add missing/new tables and modify existing tables
if any changes made with also considering column orders they created in data model
and without droping existing table because it may contain data as well as references...

2. Ef-Core Database Trigger
Database Trigger for Insert/Update/Delete required for Enterprise Level of App building
which we are doing manually.

3. MultiColumn Primary Key DataAnnotations
For better readability and maintenability we also request for this.

4. AutoColumnOrdering
Column-Ordering should be automatic sequencial by columns defined
in data model class instead of considering primary key sequence and others..

those are the main problems we found inside EF6 Core implementations.

Regards-
Sanjeeb

[ajcvickers]

@hintsofttech

1. Ef-Core Auto Migration

Automatic migrations are not something that EF Core will support.

As it's impossible to use client's resources and run CLI for every Additions/Modifications

Automatic migrations are not required to run migrations from the application. context.Database.Migrate() can be used for this.

if any changes made with also considering column orders they created in data model

Column ordering is now supported to the extent that it is supported by the underlying database system. See #10059.

2. Ef-Core Database Trigger

This is tracked by #10770. Make sure to vote (👍) for this issue.

3. MultiColumn Primary Key DataAnnotations

This is tracked by #11003, and is currently planned for EF Core 7.0. Again, make sure to vote (👍) for this issue.

4. AutoColumnOrdering

Column ordering is now supported to the extent that it is supported by the underlying database system. See #10059.

[hintsofttech]

context.Database.Migrate()

the above method only creates tables defined at first launch.
but after deployed to client
developer has to add models and modify existing models full of data if needed as well...

in that senario, it should auto add missing/new tables and modify existing tables
if any changes made with also considering column orders they created in data model
and without droping existing table because it may contain data as well as references...

[ajcvickers]

the above method only creates tables defined at first launch.

It will update the database to match the latest model, as represented by any new migrations added after the first launch.

without droping existing table

SQL Server does not allow column orders to change without dropping and recreating the table--a.k.a. a table rebuild. That being said, a table rebuild implies that the data is preserved anyway--typically by being copied to a temp table and then back again as part of the process.

[hintsofttech]

It will update the database to match the latest model, as represented by any new migrations added after the first launch.

I have done many times once initialized dbcontext by only two tables dbsets and then added one other dbset.
but the later added dbset not created....

please note that we are only calling the context.Database.Migrate() method within dbcontext constructor
and not using any kind of cli for for that...

[ErikEJ]

@hintsofttech Did you add a migration after adding the new DbSet?

[hintsofttech]

Did you add a migration after adding the new DbSet?

sir, we r not using any cli for migration just context.Database.Migrate() within dbcontext constructor...

first time initialized dbcontext by only two tables dbsets
which created two tables and worked very well.

and then added one more table dbset to the same dbcontext
without droping database.

but this time, the later added dbset not created any table in same database...

[roji]

@hintsofttech the way EF Core migrations work, is that after adding a new DbSet to your model, you must add a new migration; that migration gets added into the source code of the project, and only then can you apply it to a database. The reason for this is that EF Core needs to know which migrations have already been applied to a given database - it compares the migrations which exist in the project (i.e. which have been added) to the migrations history table in the database, which records migrations have been applied. You can read more about this in the documentation docs.

You seem to have a different idea in mind, where EF Core inspects the database and finds out which tables are missing compared to its model; this isn't how things work, and is more complicated than it seems. We have no plans to implement something like this - you have to explicitly add migrations with the CLI or similar.

[hintsofttech]

you have to explicitly add migrations with the CLI or similar.

As it's impossible to use client's resources and run CLI for every Additions/Modifications made to dbcontext models,
we have to auto-migrate those changes to clients pc when dbcontext initialized by our c# winform-app.

it should at least auto create missing new tables.

we don't have other approach to do so.
please advise the solution because it's must for customization of software as per clients requirement.

there was at least Context.DbEntity.Create() before core version
through which we managed to do so. but now what to do ?

[ajcvickers]

@hintsofttech Are your clients customizing the code. I.e. Without your involvement, do clients introduce new entity types into the model and rebuild the application?

[ErikEJ]

@hintsofttech You should use Database First with a dacpac!

[hintsofttech]

Are your clients customizing the code. I.e. Without your involvement, do clients introduce new entity types into the model and rebuild the application?

dear sirs, we don't want to involve and manually remember everything on each and every changes.
instead we want to our winform-app to auto update to client which should handle everything automatically.
and we are already doing so in before core version by Context.DbEntity.Create() method

You should use Database First with a dacpac!

this is not exact solution we wanted sir..

[ajcvickers]

@hintsofttech We aren't going to support that. Updating databases at runtime without any interaction with the user is supported. But a migration needs to be generated and included in the application by the developer when the developer changes the EF model.

[hintsofttech]

We aren't going to support that

sir at least we want to keep exposed/alive Context.DbEntity.Create() method feature
as per previous ef version so that we can migrate to ef core.

please sir...

[ajcvickers]

@hintsofttech It should not be difficult to add a migration when the EF model changes, and then apply this at runtime without any client interaction. Please use this approach when migrating to EF Core.

[hintsofttech]

this approach when migrating to EF Core

which approach sir ?

[ajcvickers]

which approach sir ?

Add a migration when the EF model changes, and then apply this at runtime.

[hintsofttech]

Add a migration when the EF model changes, and then apply this at runtime.

Is is impossible to bring back Context.DbEntity.Create() method in ef core ?

[ajcvickers]

@hintsofttech EF6 had a fundamentally different implementation of migrations which involved storing the model in the database. This was problematic in many ways, and was changed in EF Core based on experiences of what worked well and what didn't in EF6. This means that in EF Core it is possible (nor do we think it is desirable) to compare the current model with the model in the database and automatically migrate based on that. So, no, this "method" is not going to be implemented in EF Core.

Also, automatically reverse engineering the model and automatically migrating based on that is fraught with problems, and not something we did in EF6, or will attempt to do for production code in EF Core.

[roji]

To add to @ajcvickers and to give an example why this kind of automatic migration would be quite dangerous, consider what happens when you rename a property. EF is generally unable to know whether the intent is to rename the column, or to drop an old one and to add a new one (we do detect renames, but only for very restricted cases where the names are very similar). If this happens when doing the kind of automatic migrations you're asking for, then your customer would a column with all its data without even having a chance to know about it and intervene.

When a migration is added explicitly, a "possible data loss" warning is issued and the user has the opportunity to inspect the generated migration, and to possibly fix it to rename if that is the intent (see the docs).

To summarize, while automatic migrations may seem to make sense when you're just adding tables, things get complicated very quickly when you consider other kinds of migrations.

[hintsofttech]

make sense when you're just adding tables

sir, we know that altering kinds of things are complicated for automatic migration.

but adding missing tables can be automatically be mapped
and got created by dbcontext initialization.

request you to consider our requirement as it's highly needed feature to migrate to efcore..

[ajcvickers]

@hintsofttech We are not going to add this to EF Core.