3

Currently I'm trying to find a method to use EF core 2.2 for data migration. After reading the instruction at: https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/

I realise that it only support DbContext. At the moment, in my project I have mongoDBContext and IMongoDBContext for my database and I couldn't find any package that support them. I also try using Microsoft.EntityFrameworkCore.Design but it's not helping. Is there any solution for me to use mongoDbContext as the database provider, or any packages that support mongoDB as the database provider?

As for my attempt to create a migration file despite not having DbContext:

From my terminal

dotnet ef migrations add InitialCreate

Error

No DbContext was found in assembly '.Data'. Ensure that you're using the correct assembly and that the type is neither abstract nor generic.

Thank you so much!

Việt Tùng Nguyễn
  • 369
  • 1
  • 4
  • 20

2 Answers2

3

MongoDb is schema-less storage.

Entityframework Migrations is use to update schema of the tables. Yes migrations can also run update/delete/insert part of migration but only because Sql is dependent on schema.

In addition EF is not supporting MongoDb since mongo db is not using sql, mongo db has his own api/language.

Yes recent updates of EFCore supports CosmosDb but only because CosmosDB can talk sql

To sum up.

  1. If you need to modify schema probably your MongoDb design is wrong.
  2. If you want to talk to MongoDb use https://docs.mongodb.com/ecosystem/drivers/csharp/
  3. If you are not familiar with MongoDb use what you familiar with
Vova Bilyachat
  • 18,765
  • 4
  • 55
  • 80
  • Thanks for your input. The reason why I use EF core approach for my MongoDB is because I need to use something to backup and record changes made when I modify my collections and document in mongoDb for my project in Gitlab. I know other methods like using `mongorestore` and `mongodump` but that would bloat my data. Using `mongoChef` and `mongoDB Community` is not really help, either, since we need to download it to many local machines. – Việt Tùng Nguyễn Jan 25 '19 at 03:50
  • Also, since the beginning of our project there is a file `CodeFirst.cs`, which I believe, was used to run when the application is install, and I was suggested to try to use this Code First approach to migrate database despite mongoDB being schema-less – Việt Tùng Nguyễn Jan 25 '19 at 03:53
  • @ViệtTùngNguyễn if you need audit changes then look there https://stackoverflow.com/questions/3507624/mongodb-nosql-keeping-document-change-history – Vova Bilyachat Jan 25 '19 at 03:55
  • If somebody suggest you to take code first approach, then suggest them to read about mongodb ;) – Vova Bilyachat Jan 25 '19 at 03:56
  • @ViệtTùngNguyễn its two different philosophy this is why I am always asking why, Why do you use mongodb ?:) – Vova Bilyachat Jan 25 '19 at 03:57
  • Thank you for taking your time. Initially I attempted to use mongodump method as a way to version control. However, since the project is working through with Git there might be data bloating issue. And since the data is saved in BSON files, it might not be wise to download it to different local repos and modify it independently. At least, I believe that it might be a huge mess when we attempt to merge it back. – Việt Tùng Nguyễn Jan 25 '19 at 04:05
  • The same issue can also be said to mongodb tools like mongoDB Community, as I am unsure how to share it with other local repos – Việt Tùng Nguyễn Jan 25 '19 at 04:07
  • As for why using mongo, that's what we sticked to in the beginning of the project, since our project is kinda like grandnode-based – Việt Tùng Nguyễn Jan 25 '19 at 04:08
  • @ViệtTùngNguyễn http://mongodb.github.io/mongo-csharp-driver/2.3/reference/bson/mapping/schema_changes/ – Vova Bilyachat Jan 25 '19 at 04:21
  • 1
    @ViệtTùngNguyễn The point is, EF Core and all its services (design and run time) **cannot** be used without corresponding EF Core database provider component. And currently there is **no EF Core database provider** for MongoDb. – Ivan Stoev Jan 25 '19 at 09:49
0

Yes, Mongodb is shema-less storage. But a solution always has some sort of schema in your POCO/DDD typed/dynamic objects and related domain logic. And you may change these contracts over time. So with Mongo we have the ability to perform two types of migrations: upgrade scripts ( like with RDBMS) or on-the-fly document migration when documents are used. You definitely can use your MongoDB without changes in existing documents in projects like collections of metrics and IoT device data or highly dynamic objects but this is not always the case.

WhoKnows
  • 340
  • 1
  • 12