-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting Key names other than "Id" #285
Comments
Unfortunately, Id is required and used all over the framework. The interface |
I have noticed that it is indeed baked in at a few spots. And I see the reasoning. Without being able to require the key is a singular "Id" property it creates more challenges leaning on generics and more specification required when wiring up services. The issue being that you then need to pass some linq expression function to instruct it how to find the item by its key. The thing is, this can also be supplied via open generics. So I don't think that it is actually that much change. Here's what I've come up with to demonstrate
With this bit, you can ride generics a bit further...
And this works without having to take things further! It all hinges, on being able to express a where function. Doing this as part of the generics is the win here. I even managed to use IHaveIdExpressionFn on the hard delete registration. RegisterCreateWithIdExprFor is basically a clone of your AddEntityCreateCommand in your EFCore project, and RegisterHardDeleteFor a clone of AddEntityDeleteCommand. Tweaks for handler types of course. Extrapolating this further, one can see how MediatR.CommandQuery.EntityFrameworkCore.DomainServiceExtensions really could be modified to have overloaded or side-by-side helpers for AddEndityCommands etc that give this flexibility. Admittedly in my entities where I need this custom identifier, I have retained them as IHaveIdentifier but I have modified them to have the Id be decorated with [NotMapped] and made it a getter and setter for my actual identifier. A bit dirty, but it leaves less to work around and still leverage your work. I literally just had to swap out the set read method. |
First off, this is a very convenient library, especially combined with the EFC Generator, especially when your database design is "ideal."
@pwelter34 I'm curious if you have considered making it work for tables whose PK is not named "Id." Let's ignore compound keys for a moment. While Id is the EF convention, it is not an EF requirement. Wouldn't it be nice if it wasn't a requirement here?
From what I can tell, the only place that we run into trouble is in the EntityDataContextHandlerBase's Read method. The Where clause has a linq expression which is server-evaluated looking for an "Id" field. While I could add a view or a computed column to get around this hard-coded property name, folks probably prefer to keep their db as pure as possible.
One thought is that if all these EFC-facing handlers and even EntityDataContextHandlerBase were themselves implementations of generic interfaces, perhaps we could substitute other implementations to get us the desired key name in Read implentation. Just a thought.
Otherwise, the "Id" name is not an issue without code workarounds. The create/delete/update handlers don't suffer this above issue on the EF side. On the model-facing side, this is a viable workaround at the entity level to avoid issues:
The text was updated successfully, but these errors were encountered: