Code first migrations - nopcommerce 3.6

Hi guys,

Can you help me to identify the best practice to utilize EF code-first migration in  nop-commerce 3.6 solution?

I just started working on a project and most of tutorials I found, the writer usually modifies the DB schema manually, even in the "Pluralsight" course, the author used a couple of implemented methods, and gave the uninstall one literal string for the table name?

I haven't used migrations with nop as all the db scripts are already provided, but I don't see why anyone would want to modify the db schema manually while using migrations. If you I can't achieve what I want with the standard entity mappings, what I do is play with the migrations so that every sql code I need is executed within the migration (so no need to execute extra stuff manually).

In nop, I think you should do:
1- run Enable-Migrations
2.- run  Add-Migration Nop360
3.- Manually modify the migration to include Sql("") with the required inserts for nop metadata
4.- run Update-Database
5.- Modify the model as you wish (or update nop to the following version)
6.- run Add-Migration Nop3.61 or whatever
7.- Add extra Sql statements in the migration if you need it

and so on...

Hi Francesc,

Thanks for the answer. Though scripts are already provided for the existing entities and I am extending the domain with new entities.

I don`t want to have to update the DB manually off-course, yet based on a quick google search, all tutorials there are doing so.

This will take a lot of un-necessary time especially with Agile, model changes, etc.... I like your answer, yet I was hoping that automatic migrations is an option?

As I said, I believe you should be able to use only migrations and avoid modifying the db manually, but what exactly do you mean by "automatic migrations"? The first thing you need to do with migrations and nop is create an initial migration which brings the DB to the same point as the nop 3.6 installation does. From this point, you can modify the model as you wish and add new migrations whenever you want. Note you can create and delete migrations until you are happy with the result. Normally, from one version to the next you do several model changes. You can create a migration while you develop to test your code, then delete it, do more model changes and create a new migration and repeat this process until you finish the development cycle and you create the final version migration.

If you get into more advanced scenarios, you can even configure the sql generation of the migrations. I've recently done this because I needed one row inserted in a table every time a migration created a new table in the DB. Customizing the sql generation you can do these things so that you don't have to do manual steps every time.

If you show a specific problem that you face, maybe I can give you a more specific answer.

Hi Francesc,

Thanks for your follow up.

Working with code-based migrations did the trick for me. One thing to take care of though is to provide the DB connection string explicitly.

Working with automatic migrations will require me to change the DB initialize in  "SqlServerDataProvider.cs" and I don`t want to do that for two reasons:

1-Don`t want to change the platform code base for future updates

2-Working with code-based configurations is more explicit and safe, as you can name each migration file logically, that makes rolling back to a specific much easier.



Steps to work with code-based migrations if any body need it:

1-Package Manager Console -> set default project to nop.data -> Enable-Migrations
this will add a "Migration Folder" contains a "Configuration" class

2-RUN Add-Migration  -Name <any name>  -IgnoreChanges  -ConnectionString <your connection string> -ConnectionProviderName <your connection provider name>
this will create a code file for the initial migration, you will find the up method empty, that makes sense since we only need to capture the current/initial state.
you will need to provide the connection string and the connection provider name explicitly.

3-RUN Update-database
this will create the _MigrationHistory table for us with the initial/Current state of the Domain Model. This is imperative as the migration scaffold will use later to determine model changes for our next first  migration.

4-change the model as needed then RUN add-migration again with the same parameters but with a logically meaningful name.
this will result in another code file but this time with model changes in the up method.

5-Run update-database again.

6-repeat as needed.

I have found that adding any significant new functionality to nop requires extending the core source through partial classes and in some instances modifying it. I guess this is were contribution to the open source project is expected.

I have implemented this as suggested, I needed to add a default constructor to nopObjectContext with a hardcoded connection key and a connection string to the web.config so I can manage migrations in dev. I have also created an IStartupTask to fire after database initialize that will manually run the migrations on application start after deployment to live using the connectionstring in settings.txt. This is all fine for developing a branch of nop for a particular site/project from a specific version of an existing database.

However, this means that the code base cannot be re-used for multiple projects as when a new installation of nop completes it will have created both the core tables and the custom ones through automatic migration and the code first migrations become redundant.

If anyone has a suggested work around I'd love to hear it. I was thinking I could hack around with each of the generated migrations to check if it had already been applied and skip but there are no methods on DBMigration to check e.g. 'TableExists', so guessing I'll have to use an ugly try.. catch.. ignore ?

Using Entity Framework (EF) Code-First Migrations in nopCommerce for Fast Customizations - http://http://www.pronopcommerce.com/using-entity-framework-ef-code-first-migrations-in-nopcommerce-for-fast-customizations

Thanks, I had spotted that blog already. I was just moving on one step to the practicalities of deployment and upgrades, we host on Azure and would like to migrate on deployment and stand up a new instance easily from the code base.

I want to do code-first migration with Drop and Create If DB Exists method. I started doing code-first migration, performing the steps as mentioned all over the net and also in the post #153403. However, at the first stage in Enable-Migrations I received the following error:

Checking if the context targets an existing database...
The target context 'Nop.Data.NopObjectContext' is not constructible. Add a default constructor or provide an implementation of IDbContextFactory.

How can I solve this problem and reach my goal?

The problem is pretty much what the exception says. The migration infrastructure needs to instantiate the NopObjectContext but this class doesn't have a default constructor (constructor without parameters), therefore it can't construct it.

The solution is to add a constructor without parameters

public NopObjectContext()
{
}

Note that by default, a DbContext looks for a connection string named as your DbContext class, so in this case you'd need a connection string called NopObjectContext. You have several ways to specify a different connection string for the migrations.
- You can hardcode it in the constructor public NopObjectContext() : this("MyConnectionStringOrName")
- You can specify it in your migrations configuration class
- You can specify it by command line parameters when you do Update-Database -ConnectionStringName xxx (or something like this)