Fix parameter detection for custom hql method generators

[maca88]

Fix for a regression made by #2365.

Fixes #2791

[bahusoid]

What do you think of #2723?

I believe this change is not required on master if #2723 is merged. Do you see any drawbacks? All tests are green except the one I added (and most likely it fails on dialects that don't distinguish/support AnsiString type)

[maca88]

What do you think of #2723?

I think that your approach is better as we preserve the guessed type in case we would need it in the future. So probably the best would be to rebase your PR to 5.3.x and close this one.

All tests are green except the one I added (and most likely it fails on dialects that don't distinguish/support AnsiString type)

The StartsWith/Contains/IndexOf/... tests can be fixed by adding their method definition to this line:
https://github.com/nhibernate/nhibernate-core/blob/5.3.8/src/NHibernate/Linq/Visitors/ParameterTypeLocator.cs#L249

maybe we need to make this line configurable by extending IHqlGeneratorForMethod.

[bahusoid]

So probably the best would be to rebase your PR to 5.3.x and close this one.

I'm not sure. IMO it's too general change for patch release - as you can see I had to adjust few places to make it work (like in StringGenerator and CaseNode classes) . So other unnoticed regressions are also possible.

[maca88]

I understand, so a safer option would be to merge this one and remove its changes in your PR.

[PleasantD]

The StartsWith and Contains tests can be fixed by adding their method definition to this line:
https://github.com/nhibernate/nhibernate-core/blob/5.3.8/src/NHibernate/Linq/Visitors/ParameterTypeLocator.cs#L249

maybe we need to make this line configurable by extending IHqlGeneratorForMethod.

I agree that exposing the list of methods that are eligible for this relationship finding is desirable.
Since generator logic is customizable, it makes sense to me that this could be needed by arbitrary user defined methods.

Otherwise, this seems a minimally adequate solution for issue #2792