Update NHibernate to 5.3.3

[danilobreda]

The 5.2.0 version have possible breaking changes...

• 5.2.1 version

• 5.2.2 version

• 5.2.3 version

• 5.2.4 version have possible breaking changes...

• 5.2.5 version

• 5.2.6 version

• 5.2.7 version

• 5.3.0 version have possible breaking changes...

• 5.3.1 version

• 5.3.2 version

• 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.

[ismcagdas]

Is this issue in the plans for next releases ?
Thank you for your effort :).

[namer315]

Could the upgrade be done to Upgrade to 5.3.1 please ?

[i4004]

@jagregory, @chester89, @jrgcubano, can you, please, release a new version?

[danilobreda]

With these news I believe that we will have this issue resolved soon.

[hazzik]

Turns out not so easy task :) Can someone interested take a look at my PR? I need to make tests green before merging the PR.