Have recently been playing round with Entity Framework to see if it's suitable for our needs. So far have just been creating POCOs to create the Database and then using Migrations to update my schema (Add-Migration/Update-Database etc)
My question is, are we absolutely tied in with the Package Manager Console in order to manage the migrations?
From what I've seen so far, the only alternatives are as follows:
-Automatic Migrations (general consensus seems to be to avoid)
-Excuting Migrations in the code (would still involve using the PMC to create the Migration files, or would involve creating them by hand)
Is there anything else I've missed? It's not a big deal if we are tied in, but would just like to know for sure.
Thanks
Related
I am wondering about designing a EF core model of the SAP B1 database. I realize that this is a major undertaking, but I aim to start small.
This is mainly as an exercise, which may lead to something in the future.
My main issue right now, is to ensure that the DbContext is read-only.
I have found several suggestions, like this one:
How to make Entity Framework Data Context Readonly
However, that is for the Entity Framework "standard" not core, and the accepted solution does not seem to be possible with EF Core.
So, aside from using a login without write permissions, how would I go about making a read-only DbContext?
I am using EF Core 5.0.
I faced a situation where I need to maintain some database tables in sync with a Rest API. There is a daemon that keeps hitting this endpoint and has to sync the related tables.
I'm using ef core and I found only the standard Add and AddRange methods but nothing like Upsert or Synchronize. I searched a little bit and found that some proprietary nugget packages provide this but I need something open-source.
Is there a reason why this is not supported directly in EF Core ?
The project currently I'm working on, it has been changed to fluent migrator from EF migrations. What are the benefits of fluent migrator over ef migrations? Is it really worth using over EF migrations?
EF migrations are inherently code-first - you write model first, run ef commands to generate automatic migration and then update the database. No matter how sophisticated, automatic migrations are always problematic. First, things like column renames, dropping unused columns are always problematic. Additionally, if you are using F# record types or C# POCO objects, then to facilitate migrations, you often have to decorate your plain DB entities with migration specific attributes which are not desirable.
Second, EF migrations are not easily package-able as a standalone console app. Packaging migrations into a separate executable app are always a better idea as the consumer of your application would not have worry about knowing the specific commands like entity framework migration commands. Packages like FluentMigrator and DbUp makes it very easy to package into executable. However, it depends on the application needs. For example, if you are building off-the-shelf application like open source Wordpress style blogging engine and if your audience is not well versed with .net core, then migration as a dedicated utility is helpful.
You might want to choose to run ef migrations programmatically but that again is an anti-pattern as in container world, multiple container might yield race condition and needs special care, thus always better to have separate console project for this.
I have seen this question a lot around here, however all the solutions involve using EF code-first. I used model-first using a designer to layout me entities and their relationships. I would like to update my production server's scheme without losing the data.
Because I am new to this I do not know what is the best solution to achieve this goal. Could I manually write the SQL code to create the new tables in my production scheme than use database-first to import the .edmx into Visual Studio? Would that solution work?
Or can I generate the code-first representation of my .edmx and then use that migration process?
Please share some knowledge.
Thanks everyone
I've searched but haven't found much on this topic. Has anyone seen a concise "order of operations" for the DBContext, including stuff like instantiation, validation, saving, etc? I'm mainly curious because while using LINQPad with my EF 4.3 Code First context, it runs two queries before any of my own. One has to do with the migration history which I understand is because we're using EF Migrations and it's attempting to see if it needs to auto-update, and another is for the EdmMetadata table which I don't understand since it sounds like that's not necessary if we're using EFMigrations.
My lack of understanding of why the one query is called makes me wonder if there are other parts of the DBContext's lifecycle that I am unaware of that might be useful to understand/override. Thanks in advance!
The query for EdmMetadata is for compatibility reasons. EF 4.1 did not have migrations. To be able to figure out whether model changed or not the EdmMetadata table was used. Let's say you developed an app using EF 4.1 app and you moved to EF 4.3 but you did not change the model. In this case there is no need to run migrations, throw exceptions or touch the database since your model has not changed. The call to the EdmMetadata table is just to be able to handle this situation gracefully and avoid throwing or touching the database if it is not needed.
I don't think there were any other changes of this kind in EF 4.3.