-
Notifications
You must be signed in to change notification settings - Fork 685
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
Use Type as PropertyPart CustomType instead of only name #347
base: main
Are you sure you want to change the base?
Use Type as PropertyPart CustomType instead of only name #347
Conversation
- Use the constructor of TypeReference with Type argument instead of the constructor with string argument in the overloads of CustomType in PropertyPart where an explicit Type is passed. - This fixes the problem that Fluent NHibernate may map a wrong type for a property although an explicit type was passed to CustomType. This problem can happen if there are two types with names which only differ in upper / lower case. Such similar type names can e.g. be caused by obfuscation tools.
- The production code of the CustomType overloads of PropertyPart was changed to use a different constructor of TypeReference when an explicit Type was given. This caused two tests to fail although the code still should work correctly. - Change failing tests to expect the new behaviour.
Will review tomorrow |
TeamCity verified this for 4.0, but I still need to figure out if this is 3.5 compatible |
Any news on this? |
WIll take a look this week. Got lots of stuff on my plate ATM
2017-04-25 15:45 GMT+03:00 visubesy <[email protected]>:
… Any news on this?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#347 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALnfLAh6yMbtD4sEYYvfhseuOY10RdLks5rzerbgaJpZM4JE-U3>
.
--
Yours faithfully,
Gleb
|
@chester89 or @hazzik: Could you please merge this fix I provided on July 2016? |
Could you please merge the pull request? The bugfix of Fluent NHibernate works nicely with one of our products since 2016. It would be nice to have the fix in an official version of Fluent NHibernate. Or do newer versions of Fluent NHibernate support case-sensitive class names? Such class names are caused by obfuscation tools. |
Currently, Fluent NHibernate uses only the case-insensitive name of the type in PropertyPart.CustomType() because it uses the constructor TypeReference(string) instead of TypeReference(Type). This leads to problems if there are two types in the same namespace which only differ in upper case or lower case, e.g. MyProject.Abc and MyProject.AbC. CustomType() may result into a wrong mapping which uses AbC instead of Abc (or vice versa). The result depends on the order of the types in the assembly.
My commits fix that problem.
It looks like that the other classes of Fluent NHibernate already use the correct constructor of TypeReference.
I don't know if there are further places in the Fluent NHibernate code which use only case-insensitive names although a concrete Type was passed.
I didn't change the constructor TypeReference(string) to work case-sensitively because someone could depend on its case-insensitive behaviour.
Could you please pull my changes?