In EF Core, OnModelCreating scaffolds the entire database, but I don't see a way via the model builder to define a TTL; It seems like I would have to delete the container that gets created by EF Core.
Does anybody know of a better solution?
Eoleary. Although there is full support for Entity Framework Core and Cosmos DB including the EF Core Azure Cosmos DB Provider with almost full support for the CosmosClientOptions Class. The TTL component will not be available until v. 6.0 dotnet\efcore nugget package at the earliest. You can track this through the following dotnet\efcore Git Issue: Cosmos: Configure TTL per entity/entity type/collection
Version 3.1.9 is GA and version 5 release candidate is here. Additional information can be found on the dotnet/efcore project repository.
It looks like this is possible now. https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-6.0/whatsnew#configure-time-to-live
modelBuilder.Entity<Family>(
entityTypeBuilder =>
{
entityTypeBuilder.HasDefaultTimeToLive(100);
entityTypeBuilder.HasAnalyticalStoreTimeToLive(200);
});
Related
I have an application that uses Entity Framework, OData and SqlServer in a .Net core 3.1 scenario and it works great. Ultimately I want to use Cosmos DB on Azure in lieu of SQL Server.
While I can get the app to connect to Cosmos the application fails in calls to FromSqlRaw which the 3.1 compatible libraries do not support.
I've tried upgrading the project entirely to .Net core 6.0 and while this compiles without error I get problems loading assemblies using a package called MediatR (for injection) when the application starts.
My question is twofold: Do the .Net 6.0 compatible libraries for Cosmos DB correctly handle FromSqlRaw and/or is there a workaround for the problem if they do not.
If you are asking if you can send T-SQL or ANSI-SQL to FromRawSQL in EF with the Cosmos DB provider the answer is no.
Cosmos DB is a NoSQL database. The FromRawSQL is intended to allow users to send Cosmos DB's own dialect of SQL and was put in as a way to make the Cosmos provider higher compatible where the provider maybe lacked specific capabilities exposed by Cosmos DB itself.
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!
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.
If you need to modify schema probably your MongoDb design is wrong.
If you want to talk to MongoDb use https://docs.mongodb.com/ecosystem/drivers/csharp/
If you are not familiar with MongoDb use what you familiar with
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.
I'm faced with this scenario: I want to release my software into production on Azure, but there's a code-first database migration that must be applied at the same time to an Azure SQL database. During the time that new software version is pushed without the new database schema (or vice-versa), there will be a period of time that software will throw the exception The model backing the 'BlogContext' context has changed since the database was created..
My software is deployed upon pushing git commits to a branch using continuous integration in Visual Studio Team Services, so I really need a way to run update-database at the same time.
It appears this can be done using a manual publish from Visual Studio by checking the Update Database box (below), but I need this to be automated.
If you do not care about the data just drop the dbo.__MigrationHistory table
Hope this helps.
Can you take direct control over the deployment process (Team Services can help, or Octopus, Jenkins, others)? If so, deploy the database ahead of the code. That's how I would do it if I wasn't using Entity Framework. I would assume the same even with Entity Framework.
An entity framework context is initialised, by default, using CreateDatabaseIfNotExists<TContext>. If the database schema is different than the EF model, then error The model backing the 'BlogContext' context has changed since the database was created. will be triggered.
By adding to your db context contructor Database.SetInitializer<context>(null); the model error will not be triggered. This means you can deploy schema changes to production, without causing model errors, ahead of the new version of the application being deployed that contains the new db context, which equals no down-time.
Make use of an appSetting so that production code will use the null initializer.
I'm trying to create a Breeze Web API controller and I'm wondering if it is possible with the default MVC/Web API project template that comes with Visual Studio 2013. Updating everything through the Nuget packet manager installs Entity Framework 6.0.1. Attempting to installing Breeze after that results in an error as it attempts to install EF 5 as a dependency, which is not possible given the fact that other parts of the template depend on EF6.
Do we have to wait for a new version of Breeze that works with EF6?
Edit: I want to do this the "breeze way" using [BreezeController] and Odata.
I just wanted to add that even without EF6.1, the MVC 5 updates released today with VS2013 also break breeze. It's hard to separate the pieces to determine which new piece is responsible. It could be MVC or the new odata. In any case, we anxiously anticipate the new version.
Updated 10/29/13
As of now, Breeze 1.4.5 has support for Microsoft's ASP.NET WebApi 2 and Entity Framework 6. Please see http://www.breezejs.com/documentation/download.
Older post:
We don't yet support EF6 but it is coming ... soon...
There is a new package called Breeze.WebApi2 that is compatible with Web API2 and EntityFramework 6. It makes some of the existing Breeze packages obsolete. See http://www.breezejs.com/documentation/start-nuget for details.
Is it possible to change the name of the history table that the migration framework uses?
I found this: http://entityframework.codeplex.com/wikipage?title=Migrations%20History%20Table%20Customization
but I cannot derive the HistoryContext on version 4.5 of the .Net framework.
Could someone provide an example if possible?
Thanks
HistoryContext is still available to derive from. It is in the following namespace:
System.Data.Entity.Migrations.History
It is contained in the EntityFramework assembly. I can see that this is true for EntityFramwork 6. Perhaps you are using an older version? Ensure you've updated the NuGet package.