AutoEF: new project to create Code Generation layer for EF Core providers

[caleblloyd]

I would like to announce a new project I am starting to and ask the Entity Framework Core development team and Provider community for feedback.

AutoEF is a proposal to improve the provider experience by introducing a Code Generation layer to translate a Microsoft developed provider into a base implementation for third-party providers. The primary goal is for the code generation layer to do the heavy lifting when a provider updates to a new major, minor, or patch version of Entity Framework Core Upstream.

For detailed information please read and comment on the AutoEF Abstract

cc @ajcvickers @roji @ErikEJ please add anyone else in the community that you may think may be interested as well!

Update 4/21/18: Project renamed from OpenEF to AutoEF

[ajcvickers]

/cc @divega

[divega]

@caleblloyd: @ajcvickers and I had a conversations about this and here are some observations we wanted to share with you:

• We agree that the there was a lot of churn in the provider model between 1.x and 2.0. We however don’t expect the same level of churn to happen again in the foreseeable future.
• We agree that despite sharing a lot of common implementation code in the base relational provider, there is some boilerplate code that essentially all providers need to have a copy of. However it is hard to generalize because where any two given providers may implement the same behavior, a third provider may need to do something completely different.
• Some of the new features that we have added in minor releases (for example, value converters in 2.1) require changes on providers, but we have tried to add them in such a way that existing providers degrade gracefully (that is the the feature just isn't enabled, but the rest of the provider continues to work, barring the issue with usage of internal APIs that we have already discussed).

Given all of that, we believe that the general approach you describe could have some benefits, but the net gain is going to depend on several factors, e.g.:

• Churn in boilerplate/copied implementation code in future releases being higher than we anticipate
• Applicability of the SQL Server implementation to multiple providers

In the shorter term, we are still thinking that other means can yield higher benefits, for example:

• Setting up spec tests on the existing Pomelo MySQL provider and fixing issues found
• Trying to identify more opportunities for promoting repeated implementation code to the base Core or Relational implementation
• Trying to identify gaps in spec tests so that they can help inform all providers writers of what is the complete set of behaviors they need to implement.

I also wanted to share a personal opinion on the name in your proposal: To me OpenEF is confusing, because it conveys an open source flavor of EF, only that EF and EF Core are already open source! As a matter of fact, we used OpenEF to talk internally about EF6 for a while :smile:

[ErikEJ]

Agree with Diego! (Link to #11305 is broken, btw)

[caleblloyd]

Thanks for the feedback @divega and @ajcvickers!

[net gain will depend on] Churn in boilerplate/copied implementation code in future releases being higher than we anticipate

True. I think it will still be helpful to automatically pick up small changes though. It will still help the root issue of changes getting into Upstream EF that a provider misses.

[net gain will depend on] Applicability of the SQL Server implementation to multiple providers

SQL Server will be the base for OLTP providers. The Abstract talks about "feature gates" that will be put in place to optionally strip specific functionalist (memory optimized tables, HiLo sequence, etc.). This should allow providers to pick features that they want in their base.

Once Upstream provides CosmosDB #8443 that could likely be used as the base for NoSQL providers.

[short term benefit] Setting up spec tests on the existing Pomelo MySQL provider and fixing issues found

I've begun investigating Code Generation and Tests are very difficult to pull out of EF Upstream to use as a template. The test projects are not published as packages (would be helpful if they were in a MyGet feed), have a lot of dependencies on each other, and reference internal code.

It'd be nice for OLTP providers to be able to copy EFCore.SqlServer.FunctionalTests and EFCore.SqlServer.Tests as a starting point. AutoEF will provide that, but there are things we could change Upstream to make it easier.

To me OpenEF is confusing, because it conveys an open source flavor of EF, only that EF and EF Core are already open source!

This thought crossed my mind initially as well. I've changed the name of the project to AutoEF, hopefully that is more clear!

[roji]

Just wanted to drop my 2 cents here as well...

I've been playing catch-up with EF Core (and .NET Core) since the early days of beta6 (or even beta5), so I'm very familiar with the pain of having to resynchronize. @caleblloyd I understand very well where you're coming from.

At the same time, the situation has changed quite a lot, and the EF Core universe seems to be stabilizing more and more. I rarely find myself having having to deal with dramatic breaking changes, and what does happen is relatively easy to grasp and adapt.

In addition, as has been mentioned above, EF Core do publish the specification test suite. This is an invaluable resource for keeping up to date with EF Core and making sure your provider behaves properly. Fully implementing the suite is no easy task, but it can be done very incrementally, skipping test suites which you haven't gotten around to yet.

At the very least, I'd argue that implementing the specification test suite should happen anyway and should come before a code generation effort - which may still make sense after significant specification coverage is achieved (or it may not).

Finally, I'm a bit skeptical about a code generation approach here because some provider-specific code does need to be mixed into the generated classes, and it's not easy to manage this kind of thing. For services where no MySQL-specific behavior is needed, you can simply use the Relational base class (this is the default), so in any case you're only required to implement services where you have your own logic. And for those services my hunch is that you'd spend more time working on a code-generation which successfully mixes boilerplate and MySQL-specific code than you would on normal maintenance. But I may be wrong on this (or not understanding exactly what you're planning).

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.