Skip to content

Fix/prefer typehandlers for enums#2200

Open
andreasblueher wants to merge 2 commits intoDapperLib:mainfrom
andreasblueher:fix/prefer-typehandlers-for-enums
Open

Fix/prefer typehandlers for enums#2200
andreasblueher wants to merge 2 commits intoDapperLib:mainfrom
andreasblueher:fix/prefer-typehandlers-for-enums

Conversation

@andreasblueher
Copy link

Hello @mgravell,

I know there have been already 2 pull requests (#458 & #1711) for the issue #259 which haven't been merged because users might rely on the current way dapper works with enums.

Since I'm using tons of enums, I created a suggestions to introduce a opt-in flag, which allows current users to stay on their behavior and others like me to get an updated version. Since 3.0 seems far, maybe this is something you could consider merging.

Best regards,
Andreas

When enabled, Dapper checks for a registered TypeHandler for enum types
before falling back to the default integer boxing behavior. This allows
custom enum serialization (e.g. storing enums as strings via TypeHandlers)
to work on both reads and writes.

Patched locations:
- LookupDbType: return DbType.Object with handler when flag is on
- CreateParamInfoGenerator: skip integer boxing when handler exists
- GetSimpleValueDeserializer: route to TypeHandler before Enum.ToObject
- Parse<T>: route to TypeHandler before Enum.ToObject

Default is false — zero behavior change for existing users.
- Fix 6th enum-before-handler location in GetTypeDeserializer IL emit,
  preserving Nullable<T> wrapping for nullable enum properties
- Fix em-dash in comment (non-ASCII)
- Add two tests: round-trip write+read via StringEnumHandler, and
  nullable enum with null value
@mgravell
Copy link
Member

Yep, I need to find a chunk of time to chew through a ton of issues and PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants