-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
DefaultTypeMap.MatchNamesWithUnderscores is ignored for ctor parameters #818
Comments
maybe we could submit a PR for this change |
Created a PR: #1394 |
Is there anything more I need to do to get this PR merged? I am unsure if I missed out a step or if this is just due to everyone's time constraints. |
@andreas-antoniou-cko I think @NickCraver is saying it can't be added since it would break stuff. This issue makes working with postgres, records and dapper a real pain. :'( https://stackoverflow.com/questions/66624066/dapper-postgres-and-camelcase |
fwiw, this is still an issue and is still annoying. +1 for even an opt-in solution via some configuration option, anything would be better than having to alias all columns in result sets. |
Is it really so big of a deal to include the linked PR? From what I can see it looks backward compatible with the current behaviour, so this should not be breaking existing code. |
@NickCraver can you share your thoughts on this? Will it ever be fixed/implemented, or will it be abandoned? |
Completed via #1947 |
While testing the
MatchNamesWithUnderscores
property with one of my stored procedures, I noticed that if I set it to true to ignore the underscores in my proc columns, it will map them properly into class properties, but still fail for constructor arguments using the same rule.I'd expect the rule to be consistent across all name-mathing in the type mapper, as the toggle seems to imply it is for "all names" due to it's name, `Match ... NAMES ... WithUnderscores".
I want my model to be immutable, and now I cannot have properly named arguments in my code.
Would it be possible to fix this inconcistency by applying the same logic when trying to match constructor argument names as well?
The text was updated successfully, but these errors were encountered: