NHibernate.MappingException: Unique suffix 10_ length must be less than maximum 3 characters.

[Alex Bunn]

Hi all,

We've recently started seeing the following exception (NHibernate.MappingException: Unique suffix 10_ length must be less than maximum 3 characters.) being raised on our website about half a dozen times in quick succession before our website goes down, which is frustrating our customers/clients.

We've had a look over the NHibernate source code on Github, and found that the max alias length allowed by all of the various dialects is 10, which means according to the error, the first part of the generated alias is 7 characters in length with the remaining 3 being produced (10_) exceeding the remaining character limit. The limit of 10 being reached in our production environment makes no sense, as we're seeing aliases being generated in our local development machines with a length of 10,11 or 12, all of which should be generating an error.

We're currently using the most recent version of NHibernate available from NuGet (4.1.1.4000 if my IDE isn't lying to me) and currently developing in C#.

We're looking for some additional help/insight on this error so we can figure out what might be causing it, and what we can do to resolve it to make our userbase, and by extension our support/admin team happy.

Thanks.

[Alex Bunn]

Bit of an update.

After a further bit of researching, we came across NH-3899. While its not our error (Fixed in 4.1, we're currently using 4.1.1.4000), its the commits made to fix this error that seem to be causing our error.

There was 1 commit made to update the code to its current Hibernate counterpart, but another commit was made almost immediately after to prevent the alias name from becoming too long, in particular the changes made to the overloaded method 'GetAlias(Dialect.Dialect dialect, Table table)' which is being referenced in our stacktraces when this error occurs. Furthermore the changes made in this commit don't appear to be based off the original Hibernate code (and neither does the original code have these changes), so it has us questioning whether or not this is correct behaviour.

Relevant lines from the raised error.

System.Exception: Error trying to resolve Service 'TechCertain.Web.UI.Controllers.HomeController' or one of its autowired dependencies (see inner exception for details). ---> System.Exception: Error trying to resolve Service 'TechCertain.Domain.Interfaces.IUserRepository' or one of its autowired dependencies (see inner exception for details). ---> SimpleInjector.ActivationException: The registered delegate for type ISessionFactory threw an exception. Unique suffix 10_ length must be less than maximum 3 characters. ---> NHibernate.MappingException: Unique suffix 10_ length must be less than maximum 3 characters.
  at NHibernate.Mapping.Column.GetAlias (Int32 maxAliasLength) <0x41529310 + 0x00219> in <filename unknown>:0 
  at NHibernate.Mapping.Column.GetAlias (NHibernate.Dialect.Dialect dialect, NHibernate.Mapping.Table table) <0x41529240 + 0x0008d> in <filename unknown>:0 

At this stage we're not sure how to proceed. The Stackoverflow recommended solution is to create a custom class and override the 'MaxAliasLength' property, but we've tried this without success (Nibernate fails to load the class). The only other option we have is build NHibernate from source without the second commit capping the alias length and ship it in place of the official distribution. If this second commit is actually enforcing correct behaviour, then we'll have to figure out why the aliases are getting so long.

Any advice and/or additional insight would be welcomed.

[Dariusz Lenartowicz]

I have the same issue but only with SQLite driver. With SqlServer everything works fine.

[Nicholas Piasecki]

I ran into this today as well on Azure Functions with NH 4.1.1.4000. It doesn't seem to happen on my older apps still on NH 3.x, mainly because this alias length check is not there. 

Azure Functions doesn't really have the concept of host-level startup and shut down (they are supposed to be "run-once" and stateless, though this leaks out from time to time), so we end up creating a new SessionFactory on each invocation. Perusing the NHibernate source, it looks like there's a ThreadStatic tableCounter variable that is incremented when the constructor for the Table class is called. Wonderful.

Suspecting this may have something to do with it, I wrote a console app that iterated through creating 100 session factories and watching the queries it produced in NHProf, and sure enough the aliases get longer and longer because uniqueInteger climbs higher and higher. Then you explode at some point because the alias is too long.

Even the Azure Functions like you to pretend that you're running stateless, there is still a host process, and the threads that you run on may get recycled. So if you keep creating SessionFactory instances over and over -- which you aren't supposed to do, and typically don't in a typical web app, but you end up doing in a serverless framework like Azure Functions -- you will get this climbing alias length. 

Subclassing MsSql2012Dialect in my case and setting MaxAliasLength to 128 works as a temporary band-aid. But the real workaround is to just stop instancing so many SessionFactories. I moved it to a static variable to ensure that it's only instanced once, even though my Autofac container is getting rebuilt every time Azure Functions invokes my code. I hope this helps someone. 

Nicholas Piasecki

[Gunnar Liljas]

"

so we end up creating a new SessionFactory on each invocation"

Azure Functions supports static variables.

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhusers+unsubscribe@googlegroups.com.
To post to this group, send email to nhu...@googlegroups.com.
Visit this group at https://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.

[Micke]

Hi Alex, we used the "override solution" for this. Just played with NHib 5, seems it was fixed there.