Skip to content
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

Closed
julealgon opened this issue Jul 21, 2017 · 9 comments
Closed

Comments

@julealgon
Copy link

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?

@agjini
Copy link

agjini commented Jul 23, 2019

maybe we could submit a PR for this change

@andreas-antoniou-cko
Copy link

Created a PR: #1394

@andreas-antoniou-cko
Copy link

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.

@chrsin
Copy link

chrsin commented Mar 14, 2021

@andreas-antoniou-cko I think @NickCraver is saying it can't be added since it would break stuff.
@NickCraver would you accept a new boolean on DefaultTypeMapper that signifies if the stuff should work on constructors aswell?

This issue makes working with postgres, records and dapper a real pain. :'(

https://stackoverflow.com/questions/66624066/dapper-postgres-and-camelcase

@senritsu
Copy link

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.

@macco3k
Copy link

macco3k commented Nov 28, 2022

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.

@julealgon
Copy link
Author

@NickCraver can you share your thoughts on this? Will it ever be fixed/implemented, or will it be abandoned?

@mgravell
Copy link
Member

Completed via #1947

@mgravell
Copy link
Member

https://github.com/DapperLib/Dapper/releases/tag/2.0.151

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 a pull request may close this issue.

7 participants