KeyNotFoundException if identity seed does not exactly match feature enums

[jcbowers]

I cloned the repo and inserted a test feature directly using SQL which incremented the identity seed. I then found your suggestion to use the 'dotnet fbit add' command. When I added the features using that command, my FeatureBitDefinitions table's identity seed no longer matched the enum values in the sample app. Since line 53 of IsEnabled in FeatureBitEvaluator is using the Id to lookup the feature it throws a KeyNotFoundException when bitDef is null.

Expected Outcome: The way features are defined in code should be decoupled from the way SQL handles identities or even from the persistence implementation itself.

Possible solutions:

• Change the Id column in FeatureBitDefinitions to be a primary key integer with a unique constraint but not an auto-incrementing identity, that way the application can supply the identity as it defines new enums.

• Change the IsEnabled implementation to look the feature up by name instead of by Id. This would require changing the SQL script to also create a unique constraint on the name column and could break existing implementations if they have duplicate names.

• Change the application architecture to make feature resolution / persistence extendable and not as tightly coupled to the database implementation.

• Enable identity insert in the FeatureBits.Console dotnet fbit command

[themitchk]

@jcbowers - I'll bring this up to the team and review some of the suggestions. The original recommended method is to execute the command line with the generate switch. This will generate an enum based on the Ids in the DB. Example: dotnet fbit generate -n "SampleWeb".

In our projects, we use the dotnet fbit command line to manage all of our featurebits, then we execute the generate which will keep the enumeration updated.

[jcbowers]

Thank you