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 ?
Related
Microsoft provides two ways of working with cosmos dbs in C#/.NET.
One can either use Entity Framework(EF) Core, which makes use of the cosmos SDK behind the scenes and allows you to use EF with Cosmos.
This last point could be seen as positive or negative depending on if you want to use EF vs Dapper or whatever, but for my use case, I would prefer to use EF unless given a good reason not to.
Microsoft themselves has not made any statement I can find on which should be used or why. (I Assume this is a .NET Core project)
EF Core works only for SQL API of Cosmos DB as of now. So, If you are using other APIs, you cannot use EF Core.
Also, Take a look at other limitations of EF Core Azure Cosmos DB Provider Limitations at https://learn.microsoft.com/en-us/ef/core/providers/cosmos/limitations
We used Cosmos DB SDK which is quite flexible and the performance is also good.
After an experience with Cosmonaut package, EF Core and SDK I have to say that Ef Core is focused on relational mapping. Witch Document DB you need to focus on Json serialization. Ef Core model configuration feels cumbersome and limiting for document DB interaction - You have to configure things that just works while serializing. Both Cosmonaut and SDK allow focusing on serialization which in most cases just works. Cosmonaut is a convenient facade on top of SDK - but looks dead at the moment so I recommend SDK.
I'm trying to create a simple Blazor client server app using EF, similar to this article.
So I've got a client, server, and common libraries, and this worked fine. But then I added the EF component to the common library, so that I could use real data from my database, instead of toy data from the demo.
I tried making them all Core 3.0, but this doesn't work because Blazor seems to require .NET Standard 2.0. Without that, I get all kinds of errors.
But then the common library can't use EF, because (if I'm reading this right) EF6 isn't supported on Standard 2.0. If I try, I again get tons of errors.
So I'm not sure, but I can't find any scenario that would allow me to share EF objects between client and server--which is a major rationale for Blazor.
Is there some other way to accomplish this?
The shared library should not use or reference EF.
Add EF to the Server project only and make the data available through an API controller.
You should make the common project netstandard and use EF core (not EF 6)
I have a Asp.Net webapi 2 system that works with sql server. I developed it using entity fraework 6.1.3 code first data models and fluent mappings with the typical workflow of add-migration/update-database. I love it.
I have a need to create the exact same software with a lighter weight db to run on a raspberry pi device. It's the disconnected version of the software that will replay/resync all of its data to the cloud version (sql server).
I realize I may need to relax some of my constraints, but starting at the extreme, I would like to target the exact same code base with something like sqlite and xcopy deploy it to my raspberry pi and run in on mono under kestrel web server.
Ideally, I'd just like to change my connection string to point to an empty sqlite db, do a update-database and have the exact same software initially run on my windows development box (and then xcopy it over).
I have read a lot about sqlite entity framework support but a) it doesn't seem to support migrations b) it doesn't seem to support fluent mapping
I could get by using a tool to convert my sql server db to sqlite (every time I change schema) and thus avoid the need to update-database. But the lack of fluent mappings would still prevent the data model to be properly mapped to the existing sqlite schema.
Does anybody have some thoughts/recommendation for sqlite that my help me accomplish my goals?
Do you have any other database recommendations that would help me accomplish my goals - for instance I looked at vistadb, but I don't think they support fluent either.
The devart sqlite driver seems to support everything I need but their examples are all old school and AFAIK they don't have one single example that is a modern code first model with fluent mappings. And even if they did fully support code first wth fluent I am concerned there would be some syntax differences and I am not sure my existing sql server targeting code would be compatible with it. I asked the question on their forums and sent an email but haven't received a response yet.
Thanks
You could consider using EF7, which is a API compatible new version of Entity Framework, that fully supports migrations and fluent mappings with SQLite. EF7 runs on .NET 4.6 and .NET Core. Depending on what features in EF6 you use, it could be an easy upgrade, in particular since you already use Code First.
http://ef.readthedocs.org/en/latest/getting-started/linux.html
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
How can I use MVC4 Migrations without using Entity Frameworks? I would really like to use data migrations but I am not using Entity Frameworks. I am using dapper-dot-net.
Yes, you can use Migrations without using Entity Framework. All Migrations cares about is the metadata it uses to manage the database and you need to use some EF stuff to handle that, but you then don't ever need to use EF to actually access the database. This blog post describes the process in detail: http://weblogs.asp.net/fredriknormen/archive/2012/02/15/using-entity-framework-4-3-database-migration-for-any-project.aspx
Check out Insight.Database.Schema on NuGet. It gives you a lot of the magic of migrations without the hassle of EF. I'll be updating the docs on github over the next few days.