-
Notifications
You must be signed in to change notification settings - Fork 934
Use a statically resolved dialect when building the session factory #2011
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 a statically resolved dialect when building the session factory #2011
Conversation
Back-ported from 5.3 (cherry picked from commit cbc2527)
This by the way allows NHibernate.Spatial dialect hack to work again, see nhibernate/NHibernate.Spatial#104
I don't think this will help spatial, the error happens long before |
Ok, I've checked the stack trace. It should work. |
I had checked with a locally generated NuGet package with those changes, and an upgraded Spatial. Still, @peetw, can you also check this change solves nhibernate/NHibernate.Spatial#104, just to be sure? Releasing a patch takes some time, so it is better to double check. A release build is ongoing and should be available soon, with a Nuget package in its artifacts, for testing, if that helps. |
Could you also include the release notes in the PR? |
Thank you both for looking into this - much appreciated! I was away for the weekend so apologies for not replying sooner. I should have some time today to test whether the PR fixes the issue. |
I have not put them directly due to not having definitely decided what to do for #1983 (but most likely I will just add a possible breaking change notice), and also due to the suspected regression on |
@fredericDelaporte Using the NuGet package from the build artifacts, I have confirmed that this PR fixes the issue reported in nhibernate/NHibernate.Spatial#104 - thanks! |
Release commit added, adding by the way a lacking possible breaking change. |
The issue type has to be bug or task. Let’s call it bug. |
ad41b45
to
3b5ee5d
Compare
I have adjusted the releasenotes file accordingly. |
3b5ee5d
to
8bc24b7
Compare
Release commit dropped. |
This change is more a trivial optimization: when building the session factory, the dialect has no reason to change, and so we can use the same dialect instance from the start of the process to its end.
#1951, merged in v5.3, was already doing most of the work, by supplying to the built session factory an
IMapping
resolving the dialect at instantiation rather than dynamically.This PR cherry-pick #1951 into 5.2.x, and furthermore switch
Configuration.mapping
member to the mapping having a static dialect, for the duration of the build.So if anything does use the
mapping.Dialect
in steps prior to factory instantiation, it will now use that static one instead of instantiating it.Well, that does probably not actually optimize anything in most cases as far as I know.
But it allows to restore a hack used by NHibernate.Spatial, which relies on having its dialect instantiated early in the factory building process. Without that hack, Spatial users cannot upgrade to NHibernate 5.2.x.
See nhibernate/NHibernate.Spatial#104.
That is why I issue this PR, targeting the 5.2.x branch.