Otis wrote:
Am I correct that the following represents your situation:
you have an entity Product and an entity ProductType. Product has a m:1 relationship with ProductType. ProductType has a PK ID (int) and a Description field. Product's FK field ProductTypeID is of type ProductType (and not int) which is an enum, and represents the values in the table ProductType is mapped on.
(so Product.ProductTypeID is of a different type than ProductType.ID ?)
If ProductType is a 2 field entity for lookups only (as it has no real value other than to produce descriptions), is it really necessary to have the FK field set as an enum and have the relationship? the thing is that the enums are generated from the DB rows, so you can effectively use the lookups through the enums and don't need the lookup entities. I mention this as fk-pk fields not having the same types can be problematic.
Hi Frans (I must stop calling you Otis!),
Almost. Firstly, the database field type is the same in both cases, be it int, ubyte or long, so the lookup entities as attached fields are sometime redundant, but as separate entities they are useful so they are retained.
Overall, it's important top keep the DB relationship as it provides referential integrity, self-documentation, and descriptive reporting. In LLBLGen it's less important unless you want to retain the ability to access other fields such as Descriptions against the associated status of an object, so it's far from useless to retain the association, but it's obviously not an efficient thing to filter on the Name of the associated status entity.
So underlying the system, the type of Enum and type Int are essentially interchangeable and it's common to have code saying things like .Where(item => item.StatusId == (int)eStatus.Closed ) in preference to .Where(item => item.StatusId == 3)
The beauty of the LLBLGen approach is being able to say .Where(item => item.StatusId == eStatus.Closed ) with auto-completion because item.StatusId is an Enum type.
(and of course I can still get to item.Status.Description too if the related Entity is included)
So overall, we should ensure both FK and PK are represented by the same type (int or enum), and I'm suggesting that the designer warn us when we have LLBLGen relationships defined with different types. At the moment the designer stonks over the FK type with the PK type with no warning or message, and even though the underlying XML still has the user's chosen type, that's not reflected on screen.
If the warning said "Different types used in relationship X - (Company.Enums.eMyThing[FK] -> System.Integer[PK]) - [PK] has priority" then I would realise that I forgot to set the PK on tblStatusTypes to also be Company.Enums.eMyThing.
Does any of this make sense?
Cheers,
Jason