-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
Support for/ignore option for Flags Enum? #55
Comments
Thanks for raising this, it's a good point! I wonder if
I had a look at the code and there's currently code for ignoring a particular value but not a whole enum. I wonder if we still want the lookup table to be generated, might still be useful. Note to self: needs more research I think. |
You could actually support this case as well. First of all it's easy to find if a particular Enum type has FlagAttribute set which is all that is required. If this is the case instead of adding a foreign key constraint for the column one could add a check constraint and use bit masking to check if entered value is valid for column. This would be quite easy to implement. |
Does anyone have a working solution/workaround for this? |
Any solutions yet for this request? |
I won't be doing more coding on this unless I can figure out a source of funding. Suggestions welcome. See / comment on #58 |
EfEnumToLookup automatically generates lookup table and FK for flags enums.
However, the foreign key constraint will fail if one stores 2 or more flags in the enum property.
I.e. something like this will fail:
I realize that lookup tables may not convey any meaning for flags enums, especially considering the flags defined can be "overlapping" (i.e. in this example, I could define a 3rd enum member "All", with the value 3).
Is there a way to configure Ef-Enum-To-Lookup to ignore the enum type/all properties using it when generating the SQL?
My workaround so far has simply been to remove the generated FK constraint after it is generated.
The text was updated successfully, but these errors were encountered: