Incorporate re-linq into NHibernate codebase

[hazzik]

We constantly fix and patch bugs and limitations of the re-linq in our code base often duplicating the code from re-linq project. It become apparent that over these years NHibernate has overgrown the re-linq project. Also it seems that the re-linq project itself became stagnant and was not updated for 3.5 years.

So, moving forward we have a few options:

1. Do nothing and continue patch and fix unwanted behaviors. Easiest option, but it becomes harder by the days.
2. Copy full code of re-linq into NHibernate. Cleanup, remove custom duplicates, etc. This has happened in the past with LinFu proxy and logging.
3. Implement new linq provider from scratch. This is, probably, impossible task, and I just mentioned it here so we have full range of options for consideration.

[bahusoid]

Copy full code of re-linq into NHibernate. Cleanup, remove custom duplicates, etc. This has happened in the past with LinFu proxy and logging.

Thought of suggesting it myself. Totally should do it.

[fredericDelaporte]

What about: 4. Fork Re-Linq, fix the fork, publish it under a new name and make NHibernate depend on it.

[hazzik]

@fredericDelaporte its much harder than just incorporating the code. The only benefit is that we’ll be able to fix some of the bugs without releasing NHibernate itself.

But on the other side:

• we will be responsible for fixing bugs and maintain that fork
• we will be constrained by the semver changes

[bahusoid]

Yeah. Dependency on nuget looks like unnecessary complication in this case. Maybe we should still make a fork but make it part of NHibernate solution using git submodule

[fredericDelaporte]

The second proposition, incorporating the source code, has the same two drawbacks, does it not? Unless we switch most ReLinq classes to internal, but that could impend Nh-to-Linq extensibility for external implementors. Still it avoids the overhead of handling another NuGet package and another git repository.

[cd21h]

+1 for forking and publishing as a separate package. Maintaining another package is an overhead, but add more flexibility

[bahusoid]

The second proposition, incorporating the source code, has the same two drawbacks, does it not?

How it applies to we will be constrained by the semver changes? Yes - we can't delete public members, but we can modify existing and add new ones for patch release. We can't do it with separate package.

[fredericDelaporte]

Ok, And using a fork is anyway a source breaking change and may cause dependencies conflicts if we do not change the namespaces in the fork. Incorporating the source will also be a breaking change but without the risk of dependencies conflicts.

[fabiomaulo]

Philip has donated us his code. I worked with him just a bit... perhaps you can ask the same to re-linq guys. The problem is always the same: each external dependency within NH becomes, soon or later, a PITA for NH. Re-linq is "a little bit" more complicated than the dyn-proxy but the full inclusion inside NH is a very good solution. About "extensibility", IIRC, the Linq-Provider is fully injectable and, following the NH spirit, having full control over the code you can leave a lot of classes as public, overrideable and injectable.

great idea @hazzik !!!