Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Exception "EntityType has no key defined" when upgrading to 0.5 #413
I have an application using Restier 0.4-rc2 with an EF 6.1.3 dbcontext. The dbcontext uses external configuration classes to define schema, like this:
These classes are generated using the EF Reverse POCO generator. https://visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838
This all works as expected in 0.4 and a working OData endpoint is generated on top of this EF context with routes for all DbSets including Attorney.
Upgrading to 0.5 and switching from DbApi to EntityFrameworkApi, I get the error "EntityType Attorney has no key defined" when calling MapRestierRoute, even though it does in fact have a key defined both in the DB and in the configuration class. I suspect the Edm generation process is ignoring the EF configuration classes in .5 even though it did not ignore them in .4. I suspect "Attorney" is mentioned here just because it is the first one MapRestierRoute hits.
Any workaround for this would be appreciated- I'd really like to test some of the other .5 features but this is blocking me. Is there a way to ensure the Edm model is built using the full DbModel generated by EF?
In 0.5, we change the way to build model, the model is built with Web Api OData conversion model build, it reads all information from CLR class, the way it find the keys by these conversions,
You can refer to document http://odata.github.io/WebApi/#02-04-convention-model-builder, "Entity key convention" and "Key attribute" part for more detail on how key been found.
So for your case, there are two ways to fix the issue,
Either way will make model build work, let me know if this does not work for you.
Also let us know any other issues when you are migrating to 0.5 version, we want every consumers can smoothly migrate to 0.5 version. We always check issues here and questions in stackoverflow in time.
I have to disagree with this approach some. I understand the need to have a model convention for non-EntityFramework based models. But when starting from an EF-code-first model, the "thing" that should dictate the OData model IMO, is the EF model based on EF convention or configuration. My expectation would be that an Api around an EF Data Context would honor the model EF already has instead of force me to use it's own separate convention.
In this case, neither of the suggested fixes will work well due to some code gen scenarios. (The name must be AttorneyName, and adding Key attribute in the code gen will be difficult). And just conceptually, I don't want to modify my model just to make OData work.
@danroot We see your point,
We move to WebApi OData model builder for these reasons,
I reopen the issue and will think and work out how we can provide more smooth user experience like this case.