Great job by Rowan as always of explaining things and spot on demos of new interesting features! And really good questions, Rich. These are the kinds of things people frequently ask.Thanks!
Good video, but, please get a laptop that is less loud or move it away from the mic. There's an annoying high pitched/hum sound throughout the video.
Hmmm, so, EF Core isn't going to support change tracking proxies anymore and you have to implement INotifyPropertyChanged. That sounds like it will be significantly uglier to implement as a user if snapshot is too slow. For one, you won't be able to use auto-property syntax anymore. I'm not sure I have high hopes for EF Core in terms of it offering better performance when working with lots of entities. I did some testing of the new batching support. While I'm assuming it is much improved over EF 6. It still wasn't very high performing. The test I did of a million rows took 5 minutes 13 seconds for EF 7 with batching, 1 minute 55 seconds for ADO.NET Core with PreparedCommands, and 42 seconds for SqlBulkCopy. I wonder how much of the difference between EF Core and PreparedCommands came from computing what had changed versus the difference of batching the SQL versus making multiple calls using a PreparedCommand. I was hoping to move away from custom written code that I have that uses ADO.NET Core to EF Core batching. I suspect that that isn't going to happen. Especially, if change tracking proxies will no longer be supported. I don't see myself rewriting all the properties on my entities and adding INotifyPropertyChanged. That would be extremely ugly.
Stings for class members again...=( that's ugly. I understand there is no alternative but I wish nameof operator could ignore accessor modifier.
@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.
@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).
Hello guys! Quick question: where is the right place to discuss EF? I mean, I have a few non-objective questions that are neither a truly fit for StackOverflow or issues to be on Github.
For example: If I have this project where I don't wanna use a proper ORM (could be using Dapper or any other simple mapper for database access) but I do need to manage migrations, right? Can I use EF Core just to manage migrations? I mean, technically I can but does it make sense?
For me, this is the beauty of the .NET Core architecture, everything is split into small pieces so if I just want to use this or that part of something I can.