@Pavel: Yep, there isn't really a nice way around that one. The purpose of a private field is to hide the member from consuming code... but then you want to get at it from this one place :). There is a convention, where EF will find the field if it is the property name prefixed with an underscore, or a lowercase version of the property name. That works if you still have a property (i.e. the getter-only scenario).
@Jon: Our snapshot change tracking is much lighter weight than it was in EF6, so the difference between snapshot and notification is going to be a lot less in EF Core. We may have something that is more transparent than implementing INotifyPropertyChanged, but the dynamic proxies approach we took in EF6 is not feasible on all the platforms that we support in EF Core - the features we used for generating the proxies are just not supported.
If you have specific scenarios that you can share where EF Core is slow, then feel free to report them on our repo https://github.com/aspnet/EntityFramework/issues. As a side note though, bulk loading of a million rows isn't a scenario I would recommend an O/RM for. For a task like that, dropping down to ADO.NET and using native SQL Server functionality is what I would recommend doing. In a scenario like that, I would imagine the data is probably coming from something like a file, in which case even the overhead of creating an object for each record (before giving it to the O/RM) is unnecessary overhead.
Throughout the demos the performance percentages were wrongly calculated. It was radically BETTER than Rowan reported! So for instance, at the 22:00 mark ff,
EF6: 941 ms EFCore: 174ms
Rowan reported that as "Improvement: 82%"
Rather, improvement was 941/174 = 5.4 times faster!
82% faster would have been: 174 + (174*.82) = 316ms (EF6 would have been at 316ms, it's rather at 941)
I guess there could be more than one way to think of the "percentage improvement". I was thinking of the improvement as a percentage of the EF6 value - as jolleekin mentioned (941 - 174) / 941 = 82%. I think "x times faster" is also a good way to think about the speed up.
Hi. Nice stuff! When I open the EFCore101 project, and I ask the package manager to restore dependencies, it seems as though it cannot pull the rc2 bits. I get a lot of messages such as "Unable to find version 1.0.0-rc2-20270' of package Microsoft.AspNetCore.Hosting.Abstrations, etc.
Are there instructions somewhere that I can use to manually get all the bits required to run the demo projects?
Unfortunately those packages got archived off our nightly build feed (https://www.myget.org/F/aspnetvnext/). You should be able to upgrade to the latest build from that feed. I will do this to the projects on GitHub and also try to come up with a better solution to this issue - as it will happen again. Though obviously once RC2 is released I can just pin to that.
How can I the new Entity Framework to call a single stored procedure that returns multiple resultsets e.g(Select * from table1,Select * from table2,Select * from table3) . Is this supported?
This is not currently supported in EF Core (and there is no good workaround for it either). Proper stored procedure support is one of our top priorities post-v1.0.0 and will be one of the most compelling reasons for some folks to stick with EF6.x for a while.
...I have a specific issue that I am trying to work through where I have a relationship of products sold in various regions around the world. Typically I would have something like this in my context setup to do the mapping in EF 6...
...You mentioned SqlClient is planned for UWP (in the later part of video). Will this support be after v1?
There aren't specific plans/timelines on this as yet. There is general consensus between our teams (EF, SQL Client, and UWP) that it will be a good thing to enable, but we need to focus on what we are already delivering first.
@AnilApex: We will be supporting Xamarin.Forms, we just need to wait for all the changes in NuGet package layout to stabilize and for Xamarin tooling to move to a build of NuGet that supports them. This should all fall into place over the coming months.
Not to mention it will probably be awhile before other vendors release providers for EF 7. I haven't heard anything about a MySQL driver.
We are working with various provider writers so that providers will be available ASAP. Many will have them at the same time as EF7 reaches RTM. I can't comment on the specifics of MySQL - their site would be a good place to ask that question (http://dev.mysql.com/).
I also think it's weird that ASP.NET 5 apps default to EF 7.
Weird because you think it should use EF6? Or weird because you think it should use a different data access technology?
And why is it called Beta if the feature set isn't done.
As Erik mentioned, this is just a by-product of being tied to ASP.NET 5 releases. I agree, we should have called it Alpha up until the most recent releases. We just didn't think about this enough.