More streamlined workflow for early stage app development

[axefrog]

While developing a new app, nobody's using my local database other than me, so the only migration I need is the initial one. The process involves writing some code, blowing away the old state of the database and associated migrations, then generating new ones and applying them back to the database. It sure would be nice to be able to do this literally in one step.

e.g. Something like dnx ef rebuild-all and have it destroy the existing migrations, unapply them from the database, generate new migrations and apply those to the database.

[davidfowl]

I'm going to +1 this 😄

[ErikEJ]

Could you use the existing:

 context.Database.EnsureCreated();
 context.Database.EnsureDeleted();

[axefrog]

Those aren't command line options though...?

[ErikEJ]

No, those are code, so you never need to fall out to the command line

[anpete]

@bricelam Is it possible for someone to make a .cmd file to do this now, using the existing commands?

[bricelam]

Hmm, we don't expose any commands for the APIs Erik mentioned, but we have #2476 on the Backlog.

But I suppose you could, yes:

# Revert all migrations
dnx ef database update 0

# Remove last migration
dnx ef migrations remove

# Re-scaffold migaration
dnx ef migrations add InitialCreate

# Apply migration
dnx ef database update

[anpete]

@bricelam Thanks! That's what I meant.

[rowanmiller]

EF Team Triage: Obviously there are some details of implementation to iron out, but we do agree that this scenario would be good to improve. Moving to the backlog as we will look at it after our initial RTM.

[murbanowicz]

Any updates on that?
Take a look at Java Hibernate... Just set update strategy and it's done... At the moment with net.core it's painful with every change of db with code first approach

[bricelam]

I was thinking more about what this might look like today. Imagine if we allowed one temporary, non-destructive, automatic migration locally.

First, it is 100% local. It should never be shared with other team members. It could be stored in the local database. It might be stored as a temporary file somewhere for perf.

It can mutate. Just like automatic migrations in EF6, it would evolve change-to-change without any user interaction. You just change your domain model and it will diff against your local database (or maybe just the last migration) to bring your schema up to date.

It should be non-destructive. You should be able to take the schema back to the previous non-temporary migration without losing any data. Maybe instead of dropping columns and tables, it just makes required columns and foreign keys nullable instead.

It must eventually be reverted. We could do this automatically when adding or applying any migrations. Adding a migration would essentially "commit" all the changes you've done into a single migration.

...just some rough ideas I wanted to jot down.

[bricelam]

cc @glennc

[ajcvickers]

@bricelam Sounds very promising!

[fadialjabali]

hey @bricelam , do you think this can be added at some point ?

[ajcvickers]

@fadialjabali This issue is in the Backlog milestone. We are currently planning for 6.0, and will consider this issue. However, keep in mind that there are many other high priority features with which it will be competing for resources. Make sure to add your vote (👍) at the top.