2

I am using EF 5 with migrations and code first. It all works rather nicely, but there are some issues/questions I would like to resolve.

Let's start with a simple example. Lets say I have a User table and a user type table. The user type table is an enum/lookup table in my app. So the user table has a UserTypeId column and a foreign key ref etc to UserType. In my poco, I have a property called UserType which has the enum type.

To add the initial values to the UserType table (or add/change values later) and to create the table in the initial migrator etc. I need a UserType table poco to represent the actual table in the database and to use in the map files. I mapped the UserType property in the User poco to UserTypeId in the UserType poco. So now I have a poco for code first/migrations/context mapping etc and I have an enum. Can't have the same name for both, so do I have a poco called UserType and something else for the enum or have the poco for UserType be UserTypeTable or something?

More importantly however, am I missing some key element in how code first works? I tried the example above, ran Add-Migration and it does not add the lookup table for the enum.

Tyrel Van Niekerk
  • 1,652
  • 4
  • 23
  • 38

2 Answers2

2

If I understood properly your questions and what you're confused about, 

Enums support has nothing to do with lookup tables on the Db side.

Enums are simply allowing you to have properties in your classes that are Enum-s and that is translated into 'int'-s basically - so there is nothing much else in there.

For more info you might wanna look at this video from Julie Lerman on Enum-s support

hope this helps

NSGaga-mostly-inactive
  • 14,052
  • 3
  • 41
  • 51
  • I think he is saying he has a field UserTypeId that he wants to map to both an enum (lets say `UserTypeEnum`) and as a foreign key on the class for his lookup table (lets say `UserTypeClass`). – Brian Cauthon Apr 13 '12 at 18:10
  • Yea Brian, that's correct. I am trying to figure out the correct combination to have the code first be clean (using the enum's), but still creating/connected to the lookup table in the DB. I know the enum support is only on the code side, but in practice you still want a lookup table to ensure valid values in the DB. Currently here at work we have a generator that generates the enum from the lookup table (including EnumMember attributes with the description). If you use DB first with a model you can set the column to be of type enum and it creates the enum for you from the DB. – Tyrel Van Niekerk Apr 16 '12 at 12:58
  • @TyrelVanNiekerk I understand - I think you can make both work together (it's similar to custom mapping FK-s etc.). But could you just specify what exactly do you want to achieve (e.g. have enum + ID that is FK to lookup table and class - but then you have to have, I think, a lookup class too, apart from the enum - or you just want 'invisible' lookup table etc.) and I'll edit the question with a specific solution. – NSGaga-mostly-inactive Apr 16 '12 at 13:51
  • @NSGaga I ended up modifying the generated migrator code. By default, it ends up wanting to create a UserTypeLookup_UserTypeId column and FK instead of using UserTypeId. I did have to create both the enum and a lookup class to satisfy the code first/mapping/migrator code. – Tyrel Van Niekerk Apr 16 '12 at 14:35
  • Yep, definitely sounds like you need my (shameless plug) ef-enum-to-lookup nuget package - http://stackoverflow.com/a/26528355/10245 / https://www.nuget.org/packages/ef-enum-to-lookup – Tim Abell Jun 01 '16 at 15:11
0

In my experience the enum is more important to your code than the lookup class so give it the proper name. I would also keep the look up class isolated without any relationship to the User in my Model. If it trully is only for lookup, then you don't need it hanging off of your User. Your enum with a DescriptionAttribute can fulfill the lookup in your code.

UserTypeLookup might be a good name since that sounds like what you will be using it for. Then you can use that class to maintain the table.

Assuming you don't map the relationship between UserTypeLookup and User in ef code first, the only thing you should need to create in the DB manually is the foriegn key relationship between the UserType column in your User table and the PK from the UserTypeLookup table. UserTypeLookup can still be an entity and EF should still generate the DB table for it even if you don't setup any relationships for it.

Brian Cauthon
  • 5,524
  • 2
  • 24
  • 26
  • Agreed. I have in fact named my lookup class as you said. Problem I am trying to work through now is that because I set the poco to use the enum and the map code to use the lookup, the migrator is seeing that as a change and is trying to modify the database by adding a column called "UserTypeLookup". I expect to get the lookup in the DB to work I might have to resort to manually creating the table etc. in the migrator code. – Tyrel Van Niekerk Apr 16 '12 at 13:01