Managing NH provided collections

[mwpowellhtx]

Bags, collections, maps, etc... Is NH smart enough to detect if an instance is being replaced in, say, a dictionary map? Because best guess, I am seeing INSERT attempts in my database log, when I am 99% 💯 certain there should worst case be UPDATE. And which is subsequently causing kerfuffles in the reporting.

One exception being thrown in particular, The parameter type DbType.UInt64 isn't supported by PostgreSQL or Npgsql, but I have also been up and down any of my custom types dealing with anything even remotely UInt64. Also in the database logs seeinging, as I said, INSERT attempts over the possible columns, assuming UInt64 is at all valid as a root cause, and not just a symptom being kicked back consequent to a faulty INSERT over an existing table row.

Bunches of these player and bunches of those squad, and since they are all sort of glommed in the same transaction, necessarily so, it is difficult to determine exactly which column may or may not be a source of any UInt64 kerfuffles. But I can almost assuredly tell you (the royal 'anyone'), these should almost certainly be UPDATE not INSERT.

Both collections are fluently mapped as map in NH parlance, IDictionary<ulong, Player> or IDictionary<ulong, Squad>, respectively.

index: 6, value: xxxxxxxxxxxxxxxxxx, cmd.CommandText: INSERT INTO public.efcore_wbe_player (ServerProfileId, CharacterName, SteamId, FamePoints, GoldBalance, IsLinked, DiscordId, topGamesServerVoteDexJson, Id) VALUES (:p0, :p1, :p2, :p3, :p4, :p5, :p6, :p7, :p8)
index: 2, value: xxxxxxxxxxxxxxxxx, cmd.CommandText: INSERT INTO public.efcore_wbe_player (ServerProfileId, CharacterName, SteamId, FamePoints, GoldBalance, IsLinked, DiscordId, topGamesServerVoteDexJson, Id) VALUES (:p0, :p1, :p2, :p3, :p4, :p5, :p6, :p7, :p8)
...
index: 2, value: xx, cmd.CommandText: INSERT INTO public.efcore_wbe_squad (ServerProfileId, Name, SquadId, membershipJson, Id) VALUES (:p0, :p1, :p2, :p3, :p4)

index and value, values masked to preclude doxing, in and of themselves are each plausible in any event, whether INSERT or UPDATE is the penultimate intention.

As a matter of best practice, we have observability installed atop the collections, for instance ObservableCollection when IList<T> is the case, or ObservableDictionary (actually, an ObservableConcurrentDictionary) when IDictionary<K, V> is the case. We operate exclusively on the observable instance for internal affairs, and relay the corresponding thing to the source collection when necessary. In usual keeping with established NH best practices, bidirectional collections, and so forth.

Let me ask this question... are NH collections smart enough to know when values have been added, removed, replaced, in any way shape or form? i.e. if we are replacing a value, then perhaps that is interpreted as a want to INSERT (?).

Any insights would be appreciated. Also if anyone is frequentling the CSharp or dotnet or other discord channels, would be appreciated any insights via those as well.

[mwpowellhtx]

And further I ran through a debug session at the moment at which parameters are being set during the INSERT or UPDATE queries and so forth... ZERO of them are being set as a ulong, i.e. breakpoints set x is ulong the condition, did not break.

The implementation of my NHibernate.UserTypes.IUserType interface. Here are we given some value object value, and wanting it to land in a disassembled primitive P state. Which it does.

public virtual void NullSafeSet(DbCommand cmd, object value, int index, ISessionImplementor session)
{
    Debug.WriteLineIf(IsDebugging, $"{nameof(NullSafeSet)}: index: {index}, value class: {(value is null ? "null" : $"'{value.GetType().FullName}'")}.");

    if (cmd.Parameters[index] is NpgsqlParameter arg)
    {
        object x = value switch
        {
            DBNull or null => DBNull.Value,
            P p when IsPrimitive(p) => p,
            R r when IsReturned(r) => Disassemble(r),
            _ => throw new InvalidOperationException($"Unable to null safe set value type '{value.GetType()}', index {index}.")
        };

        // Added break points here, NONE of which were triggering "x is ulong" whatsoever.
        arg.Value = x;

        return;
    }

    throw new InvalidOperationException($"Unable to set null safe parameter value index {index}.");
}

The problem is not mine. Somehow the Npgsql driver is aggressively reducing the type to something else other than what we told it, or in this case somehow DbType.UInt64.

[mwpowellhtx]

I'm open to suggestions other than "minpro" at this point. Because we are doing all the correct and necessary things as far as I am aware in order to bridge a custom type, assembling, disassembling, and so forth. It's not rocket science, there is ZERO we are doing to proliferate any ulong values, they are all being delivered properly as expected decimal values.

Perhaps we downgrade, or would an upgrade have picked up a patch along the way, unbeknownst our purview somehow? Just in terms of those driver versions, we are currently running against package versions:

<PackageVersion Include="FluentNHibernate" Version="3.4.1" />
<PackageVersion Include="NHibernate" Version="5.5.2" />
<PackageVersion Include="Npgsql" Version="9.0.3" />
<PackageVersion Include="Npgsql.NodaTime" Version="9.0.3" />
<PackageVersion Include="NodaTime" Version="3.2.2" />