Update NHibernate to 5.3.3 #429
Description
The 5.2.0 version have possible breaking changes...
-
5.2.4 version have possible breaking changes...
-
5.3.0 version have possible breaking changes...
-
5.3.3 version two missing 5.3.0 possible breaking changes have been added
Possible Breaking Change from 5.3.0 for enduser
* A distributed cache may hold conflicting timestamps after upgrade for as much as twelve hours.
Consider flushing a distributed cache after upgrade to avoid any issue. Do not share a distributed
cache with applications using an earlier version of NHibernate.
* The counter id generator may generate conflicting ids for as much as twelve hours after upgrade.
* `update` and `delete` statements will now take into account any enabled filter on the entities
they update or delete, while previously they were ignoring them. (`insert` statements will also take
them into account, but previously they were failing instead of ignoring enabled filters.)
* ISession.Persist will no more trigger immediate generation of identifier.
* Bags will no more be loaded with "null" entities, they will be filtered out.
* Setting the value of an uninitialized lazy property will no more trigger loading of all the lazy
properties of the entity.
* If an uninitialized lazy property has got its value set, without any other subsequent lazy property
load on the entity, a dynamic update will occur on flush, even if the entity has dynamic updates
disabled. This update will occur even if the set value is identical to the currently persisted
property value.
* Assigning an uninitialized proxy to a `no-proxy` property will no more trigger the proxy
initialization. Moreover, reading the property afterwards will no more unwrap the assigned proxy,
but will yield it.
* A class having an explicitly implemented interface declaring a member with the same name than the
class id will have its proxies trigger a lazy load if the interface "id" is accessed.
* SQLite: in order to avoid a floating point division bug losing the fractional part, decimal are now
stored as `REAL` instead of `NUMERIC`. Both are binary floating point types, excepted that `NUMERIC`
stores integral values as `INTEGER`. This change may cause big integral decimal values to lose more
precision in SQLite.
* SQLite: non supported SQL type names previously used by NHibernate, resulting in unexpected actual typing,
have been fixed. This causes databases generated by a previous NHibernate version to fail schema validation
by 5.3 or higher versions. See #2507 for more information.
* Custom dialects used for databases that do not support cross join will have to override
`SupportsCrossJoin` property and set it to `false`.
* `VisitorParameters.ConstantToParameterMap` may contain the same parameter for multiple constant
expressions.
* `ICache` caches yielded by the session factory will be `CacheBase` wrappers around the cache actually
provided by the cache provider, if it was not deriving from `CacheBase`.
* Calling `IList.RemoveAt` or `IList<>.RemoveAt` on an uninitialized list with a negative number
will now throw an `ArgumentOutOfRangeException`.
* Calling `IList.RemoveAt` or `IList<>.RemoveAt` on an uninitialized list mapped as `lazy="extra"`
with a number that is equal or higher that the current collection size will now throw an
`ArgumentOutOfRangeException`.
* Calling `IList.Insert` or `IList<>.Insert` on an uninitialized list with a negative number will
now throw an `ArgumentOutOfRangeException`.
* Calling `IList.Insert` or `IList<>.Insert` on an uninitialized list mapped as `lazy="extra"`
with a number that is higher that the current collection size will now throw an
`ArgumentOutOfRangeException`.
* Getting or setting a value with `IList.this[int index]` or `IList<>.this[int index]` on an uninitialized
list with a negative number will now throw an `ArgumentOutOfRangeException`.
* Setting a value with `IList.this[int index]` or `IList<>.this[int index]` on an uninitialized list
mapped as `lazy="extra"` with a number that is equal or higher that the current collection size will now
throw an `ArgumentOutOfRangeException`.
* Calling `IDictionary<,>.Add` or `ICollection<>.Add` on an uninitialized map mapped as `lazy="extra"` with
a key that already exists will now throw an `ArgumentException`.
* Calling `IDictionary<,>.Remove` or `ICollection<>.Remove` on an uninitialized map mapped as `lazy="extra"`
with a key that does not exist will now return false.
* Map dirtiness is now evaluated by `EqualityComparer<TValue>.Default` when setting an existing key value
with `IDictionary<,>.this[]` on an initialized map.
* Calling `ISet<>.Add` on an uninitialized set mapped as `lazy="extra"` with a transient element that
already exists in the set will now return false.
* Calling `ISet<>.Add` or `ICollection<>.Add` on an uninitialized set mapped as `lazy="true"` with a
transient element that does not override `Equals` method will not initialize the collection.
Possible Breaking Change from 5.2.4 for enduser
* Using DML on an entity collection was applying the changes without
filtering according to the entity. It will now throw a
NotSupportedException.
Possible Breaking Change from 5.2.0 for enduser
* Entities having many non-readonly properties (including many-to-one) mapped to
the same column will no more silently ignore the trouble till an insert or update
is attempted. They will now cause the session factory built to fail. When
mapping many properties to the same column, all of them excepted at most one
should be mapped with `insert="false" update="false"`.
* Mappings mixing column elements and formula elements were taking into account
only the formula elements. They will now take into account all elements.
* Mappings mixing column elements and/or formula elements with a column attribute
or a formula attribute were silently ignoring the attribute. They will now throw.
* Mappings mixing a column attribute and a formula attribute were silently doing
some best effort logic, either considering this as a two columns mapping, the
second one being the formula (most cases), or only taking into account the
formula (case of the `<element>` mapping). They will now throw.
* NHibernate StringType has gained case-sensitivity and culture parameters.
Previously it was ignoring parameters. This type may change its behavior
for any mapping having defined parameters for this type. See #1833.
* Mapping a dynamic component with a Hashtable property instead of an
IDictionary is no more supported.
* Querying a dynamic entity as a Hashtable instead of an IDictionary is no more
supported.
* A collection mapped with a `property-ref` will no more support being accessed
when the referenced property is null. It will throw. Previously, the collection
was not throwing but was always loaded empty.
* With PostgreSQL, a HQL query using the bitwise xor operator "^" or "bxor"
was exponentiating the arguments instead. It will now correctly apply the xor
operator. (# operator in PostgreSQL SQL.)
* Auto-generated constraint names will not be the same than the ones generated
with previous NHibernate versions under .Net Framework. (Under .Net Core those
names were anyway changing at each run.) The new ones will be the same
whatever the runtime used for generating them.
* Some generated PK names may change, if a table name has a quoting symbol at
precise 13th character.
* The WcfOperationSessionContext has been removed from .Net Core and .Net
Standard builds. See #1842.
* Some classes, which were not serializing the session factory, do now serialize it.
In case of cross-process serialization/deserialization, these session factories
will need to be properly named, by setting the session_factory_name setting in the
configuration used to build them. This may mainly affect users of a distributed
second level cache, if their cache implementation uses binary serialization.
Affected classes are: CacheKey, CollectionKey, EntityKey and EntityUniqueKey.
* Some types cache representations have changed. Out-of-process second level
caches should be cleared after upgrading NHibernate, if some of those types
were cached. The concerned types are: CultureInfoType, TypeType, UriType,
XDocType, XmlDocType.
* Dialect.GetIdentitySelectString was called by the entity persisters with
inverted parameter values: the table name in the column parameter, and the
column name in the table parameter. No built-in dialects were using the
parameter values. External dialects which were using it inverted (causing issues
to collection persisters, which have always supplied them correctly) needs
to be accordingly adjusted.
* Users providing through an IObjectFactory some custom logic for instantiating
value types will now need to supply their own result transformer if they were
using AliasToBeanResultTransformer with value types, or their own entity
tuplizer if they were using value types as entities.
* Users providing through an IObjectFactory some custom logic for instantiating
their custom session contexts will have to implement
ICurrentSessionContextWithFactory and add a parameterless public constructor
to their custom context, and move their custom instantiation logic from
IObjectsFactory.CreateInstance(Type, object[]) to
IObjectsFactory.CreateInstance(Type).
* Various *Binding classes of NHibernate will now always have their protected
dialect field null. (These classes are not expected to be derived by users,
as there is no way to use custom descendants with NHibernate.)
* AbstractPersistentCollection.AfterInitialize does no more perform queued
operations. Queued operations are now run by a later call to a new method,
ApplyPendingOperations. Concrete custom implementations relying on the queued
operations to be done by their base AfterInitialize will need to be changed
accordingly.