Remove dialect instantiation in AddDeserializedMapping

[hazzik]

Replaces #787

The sole reason the dialect was created in the mapping was to generate a name for PK's in Join and PersistentClass classes.

The previous code was bothered by invoking proper rules to escape the quoting characters. But, we do not need to be concerned by the escaping rules: instead, we try to trim the quotes if we get a quote character on the edge of wanted alias sub-string.

Possible breaking change:

• Always null protected dialect field in various *Binding classes. These classes are not expected to be derived by users, as there is no way to use custom descendants with NHibernate.
• Some generated PK names may change, if a table name has a quoting symbol at precise 13th character.

[hazzik]

The "Keys" property of tables dictionary and so key here are the internal things and are not exposed outside, so we are not concerning by dialect specific qualification of it (eg catalog.schema.table in SQL Server vs catalog_schema_table in SQLite and SQL Server Compact).

[fredericDelaporte]

Is the "possible breaking change" the fact that some primary keys may have their name changed? Or something else I have missed?

[hazzik]

There are following possible breaking changes:

1. Always null Dialect property in BindMappingEventArgs. It has medium impact as it supposed to be a "user-facing" property.
2. Always null Dialect property in Mappings class and dialect field in various *Binding classes. These has low impact as they are not "user-facing" members.
3. The mentioned change in the PK name. It has a minuscule (or no) impact as it would affect only those users who have a quoting symbols in the name of a table at precise 13th character.

[fredericDelaporte]

Yes I should have thought about Dialect property switching to always null. This is not defined as a grey area breaking change. For including it in 5.2 rather than 6.0, a solution for avoiding yielding it null should be put in place. This could be done by providing a Configuration reference to BindMappingEventArgs and Mappings for allowing them to lazily get the dialect if their Dialect properties happen to be called.

[hazzik]

@fredericDelaporte what about *Binding classes?

[fredericDelaporte]

For *Binding classes, that switches to always null a field visible to sub-classes from a public non-sealed class, this is also strictly speaking a non-gray area breaking change. But it appears to me no user supplied deriving class can be provided to NHibernate for it to use them. There are no extension points for doing this. They are used as internal artifacts. Externally deriving from them has no purpose for using NHibernate.

It is then very likely than very few (if any) users may have done that. If some have done it, it could only serves purpose unrelated to NHibernate. So anyway they should have used something else as a base class. That is why I think we should accept this possible breaking change for a minor release.

(The same reasoning could be applied to PersistentClass indeed.)