Sdílet prostřednictvím

EF7 Beta 8 Available

  • Článek

Today we are making Entity Framework 7 Beta 8 available. EF7 will be the next major release of Entity Framework and is currently in pre-release.

 

EF7 may not be for you… yet

EF7 introduces some significant changes and improvements over EF6.x and therefore the pre-release phase of EF7 is much longer than other recent releases. If you are writing a production application then you should continue to use EF6.x.

Because of the fundamental changes in EF7 we do not recommend attempting to port an EF6.x application to EF7 at this stage. We will provide guidance on when this is recommended and how to do it closer to final release. EF6.x will continue to be a supported release for some time.

 

Getting started with Beta 8

We have made a modest start on documentation for EF7, you can view the current documentation at https://ef.readthedocs.org.

Supported platforms

You can use Beta 8 in the following types of applications.

Supported databases

The following database providers are available on NuGet.org and support Beta 8. See our providers page for more information and links to getting started.

We’d like to thank Shay Rojansky and Erik Ejlskov Jensen for their collaboration to provide the Npgsql and SQL Compact providers and drive improvements in the core EF7 code base.

 

What’s implemented in Beta 8

Beta 8 has mostly been about improving the features already implemented in previous betas to make them more usable and stable.

  • Basic modeling including built-in conventions, table/column mapping, and relationships
    • Fluent API (a.k.a ModelBuilder/OnConfiguring API) for configuring your model
    • Data Annotations for configuring your model
  • Change tracking
  • LINQ queries
  • Table based Insert/Update/Delete (including batching)
  • Migrations and database creation/deletion
  • Transactions (including automatic transactions during SaveChanges and explicit transaction APIs)
  • Identity and Sequence patterns for database generated key values
  • Raw SQL queries (via DbSet.FromSql)
  • Logging
  • Alternate keys including the ability to use them as keys in a relationship
  • Reverse engineering a model from an existing database

 

What are we working on now?

The following features are currently being implemented

  • Cascade delete support
  • Table-Per-Hierarchy inheritance pattern
  • .NET Native support

Aside from the in-flight features listed above, our efforts from now until our initial release will be on cross-cutting quality concerns.

  • Bug fixing
  • Performance tuning
  • API reviews
  • Documentation
  • etc.

 

What about EF6.x?

Given that we have said EF6.x will continue to be a supported release, and that we will continue with bug fixes and small improvements to the code base, you may be asking why there hasn’t been much activity on the EF6.x CodePlex project for the last 6 months.

For the lead up to initial release of EF7 we are having our team focus almost solely on the EF7 project, but once we get EF7 stabilized and ready for release we will be transitioning back to dedicating some time to work on EF6.x. Our initial focus will be to get a pre-release of EF6.2 available. This will start with processing the outstanding pull requests and fixing the bugs we have already allocated to the EF6.2 release. We anticipate having the first preview of EF6.2 available shortly after EF7 reaches RTM.

Comments

  • Anonymous
    October 15, 2015
    The comment has been removed

  • Anonymous
    October 15, 2015
    I suppose most developers (as we) have an existing DB. Please let us generate the code from DB.

  • Anonymous
    October 15, 2015
    A missing feature that will help us modelling Domain Driven Design architectures is to allow to map private setters. The alternatives for this are a waste of time. NHibernate supports this from several years ago. I think its time to take it in account on EF7.

  • Anonymous
    October 15, 2015
    Plus, how can I map an arbitrary type of data to a CLR object? For instance, if I have a XML, JSON or even a simple int field, how can it be directly mapped to a RGBColor type using Fluent API? Property(u => u.Color).HasColumnType("int", typeof(RGBColorConverter)); Why does not HasColumnType have a type converter parameter? I understand this operation can be expensive especially if you load a list of entities, but it can be avoided with LINQ projection or an own SP.

  • Anonymous
    October 15, 2015
    From the looks, this is yet another attempt for Microsoft trying to solve their ORM problem. You should really get NHibernate as an example. People who designed NHibernate really grasped POCO concept very well.

  • Anonymous
    October 16, 2015
    @Laci, "Reverse engineering a model from an existing database" is listed under the "What’s implemented in Beta 8" section. This is the feature you're looking for.

  • Anonymous
    October 16, 2015
    Batching has got to be one my favorite improvements in EF7. Can't wait to try it out! Keep up the good work. :-)

  • Anonymous
    October 16, 2015
    We're using POS Plain Old SQL in our new applications and slowly removing ORM from our older systems to reduce ongoing costs, reduce points of failure, reduce need to rely on libraries/tools likely to be unsupported, killed or undocumented in the next 5 years.   2-3 guys with a gaggle of random blog posts is not product support - refer to PRISM being moved from MS patterns and practices to an outside couple developers. EF sped up development during the first 6 months of a 2 year development cycle, then was level for the next 1 year, and then starting costing us significant amounts of time and money over the next 3 years.   It was determined near the end of the applications 7 year lifespan that ORM became less used over time with more and more queries going directly against SQL Server instead of through a ORM.

  • Anonymous
    October 16, 2015
    Will "work an cascade delete support" include support for On Delete Set Null? Always puzzled me why this is absent in EF.

  • Anonymous
    October 17, 2015
    @Ron So your alternative to an ORM is hardcoding SQL strings and then what? Reading the untyped results into objects yourself? Doing this is just doing ORM by hand, and it invariably leads to hard-to-catch type bugs when the programmer thinks the database will return one type but returns a slightly different type (via nullability, precision, etc). My question is do you expect to have tooling in VS to reverse engineer from database by RTM? This is the most important aspect for us. Really looking forward to trying the surrogate key support and bulk operation support out.

  • Anonymous
    October 17, 2015
    @DabblerNL yes, the functionality is already implemented in current nightly builds. You will have to explicitly specify it in the model using .OnDelete(DeleteBehavior.SetNull).

  • Anonymous
    October 17, 2015
    Is support for NoSQL DBs (like at least your DocumentDB, or maybe MongoDB) going to appear in the nearest future?

  • Anonymous
    October 18, 2015
    Not sure why an oracle provider is not included right out of the gate???  It is one of the most widely used databases on earth, if you guys really want to mix it up in the linux world then have an oracle provider ready in the beta stage would have been one of my goals.  Maybe I should write it myself??? Let me research how difficult it is  (probably extremely hard as it seems to be always be the last provider written and is typically written by some 3rd part or oracle themselves) and see if it is reasonable for me to spend some time on this.

  • Anonymous
    October 19, 2015
    Can I use EF7 with TypeScript?

  • Anonymous
    October 19, 2015
    The comment has been removed

  • Anonymous
    October 19, 2015
    @Laci – to add to what @bricelam said, the Scaffold-DbContext command in Package Manager Console is what you are after. We will have visual tooling by the time we RTM.

  • Anonymous
    October 19, 2015
    @Alberto León – Private property setters work with EF6.x and EF7 (I think they also worked in EF5).

  • Anonymous
    October 19, 2015
    @daywalker – You can’t map arbitrary data types yet, though we have built out the architecture with this scenario in mind so that we can enable it later (it’s tracked by github.com/.../242).

  • Anonymous
    October 19, 2015
    @Ron – I’m not going to try and talk you into using an O/RM… if you have a data access strategy that is working well for you then that is great. We provide EF for folks that want an O/RM… but it’s just one option out there and it’s definitely not for everyone.

  • Anonymous
    October 19, 2015
    @Andriy – Yes, we prototyped a couple of non-relational providers to make sure the core architecture worked for them. Our focus for the next few months is on shipping a stable product with a limited set of providers, but we absolutely still want to build out some non-relational providers.

  • Anonymous
    October 19, 2015
    @Derek – we are working with a number of provider writers on getting the EF7 providers up and running. Some of those are open source and/or happy for us to share details of their plans – others prefer to keep things under wraps. I can’t comment on specific providers other than the Npgsql and SQL Compact providers who are being very public about their development.

  • Anonymous
    October 19, 2015
    @Louis van Geldrop - No, EF7 can only be used in .NET applications.

  • Anonymous
    October 19, 2015
    The comment has been removed

  • Anonymous
    October 19, 2015
    OK.  Found the answer to my own question. Once I added using Microsoft.Data.Entity, I found those functions.

  • Anonymous
    October 19, 2015
    We are evaluating EF with a code first usage of >300 Entities in one dbcontext: Startup time is > 45 secs with EF6. This is incredible slow! Then I saw a pull request on codeplex: "#1876 #2631 CodeFirst Startup Perf " I tested it and this reduced startup time to about 4-5 secs which would be ok. I would like to know now if that pull request will be accepted by your team and what would be the timeframe. Would we speak about 2016Q1, Q2 or even later.

  • Anonymous
    October 20, 2015
    Any chance you will implement EntityDataSource for EF7? Telerik uses this for their grid control and it works great. It has built-in paging, filtering, sorting, etc. I have a bad feeling that Telerik is going to lag with coming up with an alternative solution and I will be stuck with EF6. For a long time at least, Telerik still had a long of examples using LINQ to SQL. How does EF7 handle creating queries dynamically? I don't know if EF7 is fundamentally different in this regard. I just really want to upgrade to EF7. Query performance in EF6 isn't very good. As far as I  know, you have to use Include() which results in huge sets of data coming back. I think allowing things to be lazy loaded would be better. I've been doing similar queries in Java with JPA and EclipseLink and found that that's what it does. The queries seem faster because it's only displaying a page of data. The main query is simpler. I think it also has a second-level cache which may be what's making the difference. I saw that EF7 has a new way of handling this. So, I really want to take advantage of that. Also, startup time in EF6 is pretty abysmal. I have a model with about 800 entities. It takes 50 seconds to initialize on the server. 20 seconds on my desktop. I also want to use the batching. EF6 is terrible for batch loads of any kind. I ended up creating a T4 template for CRUD methods and roll my own. Mine uses prepared statements, something EF 6 doesn't do. However, mine doesn't use batching. So, I'm hoping that EF7 will surpass what I've done. I really hope that support for EntityDataSource isn't dropped. Microsoft stated that it's being dropped, but, I hope they reconsider this.

  • Anonymous
    October 20, 2015
    @Rowan Miller: Could you provide us a sample how to map private fields (collections) in EF?

  • Anonymous
    October 22, 2015
    Guess I am waiting to move to 7.1 or later.  No TPT inheritance is a deal breaker with our existing databases being accessed by EF 6.1.3.  TPH may be faster, but there is no way our DBA is going to change the existing database schemas to suit 1 or 2 applications.

  • Anonymous
    October 23, 2015
    Hi Rowan, looking great but please do not forget database views! github.com/.../827 Reasons are found in issue so I hope you understand why this is super important for us. Can you say when this is coming? Thanks!

  • Anonymous
    October 27, 2015
    How would I get started if I want to write an EF7 provider for another database, say Firebird?

  • Anonymous
    November 05, 2015
    I’m doing some test with asp.net 5 beta8 and Sqlite, however sqlite is only running at runtime 1.0.0-beta8 clr x86. Perspectiva have any of Sqlite work with x64 architecture.

  • Anonymous
    November 11, 2015
    I'm currently testing EF7 Beta8, and noticed some unusual behavior. Note that I'm using the EntityFramework7.Npgsql  provider for postgresql. I don't know if the issue is the provider, the EF7 core, or my code, but anyways, the issue is that I used to have a column in one of my entities, but refactored some stuff and it's no longer part of the entity, and also no longer part of the database, but the "model" that gets built at runtime somehow has the old column. and it's complaining that the database doesn't. So, my question is how do you go about debugging these types of things.  

  • Anonymous
    November 11, 2015
    Just wanted to note that I figured out my issue and it was my code.  I was refactoring some code and left a property reference to another entity in one of my entities. The "convention" took the name, added "Id" and made it a property in the "model" created at runtime.  One of the things I did with EF6 was disable the conventions (using some reflection based code calling Remove on any IConvention class).  I prefer to have all my mappings explicitly defined. This may seem silly to some, but that's just the way I like it -- to keep from having to add "NotMapped" to all entity properties that aren't going to be mapped -- I prefer to keep the entities from having attributes all over the place). Anyways -- hope you add a simple "optionsBuilder.UseConventions(false)" that can be added in OnConfiguring. Cheers

  • Anonymous
    November 12, 2015
    What is the timetable for connecting Azure to EF7? Specifically I am looking for Azure Tables support. Keep it up and I am looking forward to the release.

  • Anonymous
    November 12, 2015
    The comment has been removed

  • Anonymous
    November 12, 2015
    Oops.  Above name should have been TTRoadHog NOT TTRoadHor!

  • Anonymous
    November 17, 2015
    I noticed that MapToStoredProcedures is missing. Is this present in another form or is the stored procedure support not implemented yet?

  • Anonymous
    November 18, 2015
    @ Vincent – Quite a few things in EF7 are extension methods… as you found, you just need the Microsoft.Data.Entity namespace to get them.

  • Anonymous
    November 18, 2015
    @ Heinz Ernst – Yes we are planning to take that pull request in EF6.2. See the “What about EF6.x” section of the post for more details about that release.

  • Anonymous
    November 18, 2015
    @Jon – Honestly, I don’t have a definite answer on EDSC. At this stage we are not working on it, but if we see enough folks ask for it then we will reconsider. Sorry, I know that’s not the response you want – but just being straight with you.

  • Anonymous
    November 18, 2015
    @Igor Mystit – You need to have a property for EF to be able to use a collection, but it doesn’t have to have a setter (or even be public). So you can have a public getter-only property that is always initialized (EF will only try to set it if the collection is null). Alternatively, you can have a private property and then public Add/Remove methods. Having a straight up private field with Add/Remove methods is not supported yet.

  • Anonymous
    November 18, 2015
    @Gareth Suarez – That makes sense. Our guidance is to only use EF7 if you are ok with the limitations. EF6.x is still a perfectly valid version to be using and requiring TPT would be one of the good reasons to stay there. BTW there was initially some discussion about whether we would ever implement TPT in EF7, but we’ve had enough feedback to make it clear that it does need to be implemented (and thus we will).

  • Anonymous
    November 18, 2015
    The comment has been removed

  • Anonymous
    November 18, 2015
    The comment has been removed

  • Anonymous
    November 18, 2015
    @Marcos Paulo – SQLite should now work on x64 with the latest release. Feel free to open an issue if you are still seeing a problem github.com/.../issues.

  • Anonymous
    November 18, 2015
    @ JeffGillin – probably best to open an issue on our repo and be sure to include code that shows us how to reproduce it. Then we can work out what is going wrong. github.com/.../issues

  • Anonymous
    November 18, 2015
    The comment has been removed

  • Anonymous
    November 18, 2015
    @Bernhard – Stored procedure mapping for INSERT/UPDATE/DELETE is not implemented yet. This would be one of the most common reasons to stick with EF6.x for the time being. You can track the item here github.com/.../245.

  • Anonymous
    November 24, 2015
    Rowan, how would I proceed if I wanted to use Identity framework, but didn't want to use EntityFramework? What would I need to implement for e.g. just allowing me to validate a login?

  • Anonymous
    November 30, 2015
    @Bernhard - Probably best to follow up on the Identity project github.com/.../Identity. RoleStore and UserStore look like the main ones you need to implement.

  • Anonymous
    December 03, 2015
    The comment has been removed

  • Anonymous
    December 07, 2015
    @Paul - I just tried on a Win10/VS2015 machine and did not see the same issue. What version of NuGet Package Manager do you see under Tools -> Extensions & Updates? I have 3.3.0.158 and am wondering if you have something earlier?