Add/Rename/Delete/Data Type Changes of Column Should Auto Be Modified In Database Table By EF Core

[hintsofttech]

Error After Add/Rename/Data Type Changes of Column

1. if sequential column added in record/class add column with provision of default value/null can be managed.
2. for rename a column in a sequence should also catch according to table available in backend.
3. for delete it's very easy to delete missing column from database all together.
4. for data type change is still the same process can be applied if tried well.

[roji]

@hintsofttech you seem to be proposing changes to EF Core's Migrations feature, but I'm not clear on exactly what you're asking. Can you please elaborate each point and provide examples?

[hintsofttech]

@hintsofttech you seem to be proposing changes to EF Core's Migrations feature, but I'm not clear on exactly what you're asking. Can you please elaborate each point and provide examples?

Yes, We mean EF Core's Migration feature but without actually any manual migration... it should auto make changes accordingly without even the need of migration...

[roji]

Sounds like you're asking for automatic migrations, see #6214; read through that issue to understand why we've decided not to implement that.

[hintsofttech]

Sounds like you're asking for automatic migrations, see #6214; read through that issue to understand why we've decided not to implement that.

But none is satisfied by avoiding automigration. This should be available optionally. If needed, developer should enable it.

[roji]

Duplicate of #6214

[roji]

@hintsofttech the EF recommendation is either to use Migrations, or to use EnsureCreated/EnsureDeleted in testing and in various early stage development scenarios. We do think we can improve on the early prototyping phase, but we don't intend to do that via automatic migrations.

[hintsofttech]

@hintsofttech the EF recommendation is either to use Migrations, or to use EnsureCreated/EnsureDeleted in testing and in various early stage development scenarios. We do think we can improve on the early prototyping phase, but we don't intend to do that via automatic migrations.

But please try to understand the following cases where there must be automigration should exists:-

1. For winform apps not connected to server and there is no any communication between client and developer. No cli tool can be used.
2. You think only for Stable Entity. But what about additional features required against same model ?
   Must be auto migrated on app updates.
3. And so on ...

[roji]

For winform apps not connected to server and there is no any communication between client and developer. No cli tool can be used.

I don't understand - if there's no connection to any database, what is it that you're expecting EF to do?

You think only for Stable Entity. But what about additional features required against same model ?
Must be auto migrated on app updates.

I don't really understand what this means.

In general, it's very hard to understand exactly what it is that you're asking for. Showing some precise code with exactly what you want would be helpful.

[hintsofttech]

For winform apps not connected to server and there is no any communication between client and developer. No cli tool can be used.

I don't understand - if there's no connection to any database, what is it that you're expecting EF to do?

You think only for Stable Entity. But what about additional features required against same model ?
Must be auto migrated on app updates.

I don't really understand what this means.

In general, it's very hard to understand exactly what it is that you're asking for. Showing some precise code with exactly what you want would be helpful.

Why r you all not understanding ? Clients just download our installation setup file and install. In that case if we change our model, our clients, after every update, suffer errors untill we manually change the design of the table to match with our c# model. They just make payment online and use our app. We don't want them to contact us for every updates. Actually we want our updates with automatic treatments for any changes. if automigration works, these problems will automatically be solved.

[ErikEJ]

@hintsofttech Have you looked at migration bundles?

[hintsofttech]

@hintsofttech Have you looked at migration bundles?

sir, we never add migration.
that's why no need for bundles as well.
but we are aware of migration bundles.

still we believe why should we bother for extra more steps
if can be achieved through auto migration for the things for changed in dbcontext ?

after all we are programmer and we make things simplest but we are making it complicated ???
in ef6, there was at least some extend of auto migration for us which we benefited
but in ef-core it's still nobody even planning for.
are we not downgrading the features ?

auto-migration is the need for most of the erp-programmers.

please consider...

[ErikEJ]

If you use Database First, put your database schema in a .dacpac and run dacpac publish as part of your setup.

[hintsofttech]

If you use Database First, put your database schema in a .dacpac and run dacpac publish as part of your setup.

And what about changes made after installation
Which will cause errors if app updated by client ?

How will be following be updated automatically ?

1. New tables added to dbcontext.
2. tables modified and some dropped as well.
3. Columns Add/Rename/Delete/Data Type Changed

[roji]

@hintsofttech as I wrote above, read #6214 for reasons why automatic migrations weren't a good idea, and didn't work well in EF6.

Interestingly, when users ask for automatic migrations, they frequently do so for the early prototype, whereas you want them to be used in production scenarios. What's your exact reason for not wanting to use regular Migrations? After all, it only requires you to perform a minimal gesture to generate the migration (dotnet ef migrations add).

[hintsofttech]

Sir, as you know migrations requires a lot of attentions for what have been changed which we don't want to track it for even simple-simple changes.
It should be auto tracked by ef core making all differencial changes updates to the client db.
Or you can provide us ...

dbcontext.database.migrate() method

through which we could do it wheneven client update our app and all the changes made takes effect for that client.

[roji]

Or you can provide us ... dbcontext.database.migrate() method

This exact API already exists, see these docs. It allows you to apply any new migrations automatically when your application starts up.

[hintsofttech]

Or you can provide us ... dbcontext.database.migrate() method

This exact API already exists, see these docs. It allows you to apply any new migrations automatically when your application starts up.

sir, we tried dbcontext.database.migrate() method for followings:-

1. New tables added to dbcontext.
2. tables modified and some dropped as well.
3. Columns Add/Rename/Delete/Data Type Changed

nothing changed to existing database...
i.e. it's not working ...

[roji]

@hintsofttech did you generate a migration first, e.g. by running dotnet ef migrations add? This is all described in detail in our documentation on Migrations.

The flow is that as the application writer, you generate a migration after making a code change. For example, after changing the name of a property, you run dotnet ef migrations add, which generates a migration to rename the corresponding column in the database. Then, when your client starts the application, DbContext.Database.Migrate() checks their database, detects that the schema is out of date, and applies your new migration, renaming the column.

[hintsofttech]

sir when I call dotnet ef migrations add from cli
No project was found. Change the current working directory or use the --project option.

[roji]

@hintsofttech you're probably executing the command in the wrong directory; you need to do this in the directory of your C# project which reference EF Core and has your DbContext definition.

I suggest giving our Migration introductory page a good read; this should make you familiar with the basics.

[hintsofttech]

@hintsofttech you're probably executing the command in the wrong directory; you need to do this in the directory of your C# project which reference EF Core and has your DbContext definition.

I suggest giving our Migration introductory page a good read; this should make you familiar with the basics.

thankx a lot sir, it's working as desired except

1. I changed column order that didn't work, why ?
2. can we also migrate sql-server-triggers, procedures, functions and views ?

[roji]

Glad to hear it's work for you.

Changing column order after table creation simply isn't supported by the majority of databases (IIRC only MySQL supports that).

Re triggers/procedures/functions/views: these are database objects which aren't modeled in your EF model. In other words, EF can derive a table definition from your .NET types (.NET properties -> database table columns), but e.g. a view is just an arbitrary SQL query which you need to specify yourself. So you'll need to manage these yourself, but Migrations allow you to easily integrate raw SQL into your migrations - see these docs. This allows you to e.g. insert a CREATE VIEW into a migration to cause that to be created/altered/dropped.

[hintsofttech]

sir, but here is problem that

suppose thousands of migrations we added
we deleted migration folder all together
and added new migration
now question is,
will it work for client databases
against our packed last new migration
and will apply to their any level of data version
by different level of changes ?

sir, ef core is comparing all the migrations one-by-one and changing all of then sequentially.
instead, we think
ef core should only compare
1. c# latest migration added and actual database on client side and not migration table
or 2. c# latest migration added and last migration on client side table

but prior is better approach because client side migration table data maybe missing anytime....

which make sense for real changes to be migrated.
We think this will be the best approach.

[roji]

we deleted migration folder all together

This not something you should be doing. We do have #2174 tracking the ability to squash migrations, for when too many migrations start to become a performance issue. But this typically happens only in very extreme cases, or when migrations are misused (e.g. with data seeding of huge data). In almost all regular scenarios, migrations scale well.

In other words, I advise you to consider why you're thinking about deleting your migration folder.

sir, ef core is comparing all the migrations one-by-one and changing all of then sequentially

That is not what EF does. It checks the migrations history table in the database to see which migrations have been applied, and applies the missing ones.

ef core should only compare

There are various reasons why this does not work as a scalable approach. As I advised several times before, read #6214 thoroughly to understand why we don't intend to implement automatic migrations.

Note that we've had this same conversation before several times already, in #27160 and in #27195.

[roji]

Duplicate of #27160

[hintsofttech]

sir, we agree with 👍
https://github.com/dotnet/efcore/issues/6214

complete understanding is very clearly provided by rhyous sir
but none is trying to understand him.

the same thing we are also trying to make clear that
no history in c# as well as database is required.
if executed properly. just c# model and database table only to compare and make changes if difference found.
so simple, but we know our .net team has predefined not to go through this simple pathway...

we humbly request you all try to listen us think once again
to bring our ef core package on top of all heads.

[roji]

@hintsofttech I posted a long comment explaining all this in #6214 (comment).

I'll go ahead and close this issue as no new information has been raised compared to the older issues discussion this.