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

Use Type as PropertyPart CustomType instead of only name #347

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

visubesy
Copy link

@visubesy visubesy commented Jul 5, 2016

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?

- 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.
@chester89
Copy link
Collaborator

Will review tomorrow

@chester89
Copy link
Collaborator

TeamCity verified this for 4.0, but I still need to figure out if this is 3.5 compatible

@visubesy
Copy link
Author

Any news on this?

@chester89
Copy link
Collaborator

chester89 commented Apr 25, 2017 via email

govorovvs added a commit to govorovvs/fluent-nhibernate that referenced this pull request Nov 16, 2017
@visubesy
Copy link
Author

@chester89 or @hazzik: Could you please merge this fix I provided on July 2016?

@visubesy
Copy link
Author

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.

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