I mapped a database view with DbQuery in a much older Entity Framework version. Now as I upgrade that property is always null. Checking the docs for EF 6 I find absolutely nothing about database views.
How can I map a view? (I do not need migration, just the mapping).
Any official docs?
Related
Is it possible to deploy / install Entity Framework Core 2.0 alongside traditional Entity Framework 6? Is it fully possible, or possible but with some hang-ups, or not possible? Is this documented somewhere? I think I've seen they said they designed it to be side-by-side, but I'm having a hard time fully confirming this. Thanks.
The official documentation says the following:
It is possible to use EF Core and EF6 in the same application. EF
Core and EF6 have the same type names that differ only by namespace,
so this may complicate code that attempts to use both EF Core and EF6
in the same code file.
If you are porting an existing application that has multiple EF
models, then you can selectively port some of them to EF Core, and
continue using EF6 for the others.
This means of course that you can install both EF6 and EF Core in the same project. I have done this in a few simple cases myself and it was working ok.
I am new to the ADO .NET technologies. I know EF6 is built on top of ADO .NET. I checked out some of Microsoft's Data technologies reference site (http://msdn.microsoft.com/en-us/data/).
I am trying to figure out if a CodeFirst created database that is modified after initial creation can be modified and migrated without loss of data. One of the tutorial videos on their site says DatabaseFirst EF mappings created with the entity designer cannot be migrated without loss of data after a change is made to the schema.
Do migrations for changes to schemas based on CodeFirst designs also suffer from that problem of data loss after migration?
This is good article you should read:
http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework-in-an-asp-net-mvc-application
In the deployment section you saw the MigrateDatabaseToLatestVersion
initializer being used. Code First also provides other initializers,
including CreateDatabaseIfNotExists (the default),
DropCreateDatabaseIfModelChanges (which you used earlier) and
DropCreateDatabaseAlways. The DropCreateAlways initializer can be
useful for setting up conditions for unit tests. You can also write
your own initializers, and you can call an initializer explicitly if
you don't want to wait until the application reads from or writes to
the database. At the time this tutorial is being written in November,
2013, you can only use the Create and DropCreate initializers before
you enable migrations. The Entity Framework team is working on making
these initializers usable with migrations as well.
For more information about initializers, see Understanding Database
Initializers in Entity Framework Code First and chapter 6 of the book
Programming Entity Framework: Code First by Julie Lerman and Rowan
Miller.
quoted from that article.
I'm trying to move an ASP.NET MVC 5 application to MVC 6 (ASP.NET vNext).
My existing application uses EF 6 and has some EF code first migrations. I want to port these migrations as well, because I want to be able to continue using the existing databases with the existing migrations already applied, without breaking the upgrade path.
It seems that the "new" EF Core migrations (k ef migration add ...) have quite the different format compared to the "old" EF 6 migrations:
No more Designer partial class
No more RESX file
Is there already an "official" way to upgrade these migrations? Is it supported at all? Will it be supported in the future?
There isn't really a way to do this yet. In general we strongly recommend against trying to upgrade an EF6 application to EF7 yet. EF7 is still very much pre-release.
We will have some guidance on how to do this when we get closer to RTM. We may provide some tools to help or just some guidance on how to do it.
Date: 13/April/2016
As of now it is not advisable to use EF7 in production because of following limitaions
"Because of the fundamental changes in EF7 we do not recommend attempting to move an EF6.x application to EF7 at this stage. If you want to move to EF7 to make use of new features, then make sure you are aware of the limitations of EF7 before you start. You should view the move from EF6.x to EF7 as a “port” rather than an “upgrade” ".
One area of RC1 that has a number of outstanding issues is our query pipeline. The majority of issues result in an exception when you attempt to execute a LINQ query that contains a particular pattern. There are often ways to workaround these issues by expressing the same query using different patterns, or evaluating parts of the query client-side. We try to include these workarounds in the issue, when they are available.
In RC1, there are a number of scenarios where EF7 performs slower than EF6
More Readings:https://blogs.msdn.microsoft.com/dotnet/2015/11/18/entity-framework-7-rc1-available/
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.
I'm working on a project that uses ADO.NET entity framework as the ORM framework for getting data in and out the database. This all works great, but there's one association that I don't want to map. At least I don't want the developers to navigate from Product to OrderItem using the association between them.
Has anyone tried this scenario before I knows whether this will work and how I can model this into my domain-model?
In EF 1 you can remove the relationship from the client schema in the EDMX and it will work fine, but I think it confuses the GUI designer. I believe this is fixed in the EF 4 designer.