How to map table with two references

[mwpowellhtx]

I have a table Vehicle with effectively two references. One to MotorVehicleDivision which must exist.

References(x => x.MotorVehicleDivision)
    .Not.Nullable();

Another to Owner which may or may not exist. In context vehicle may be found in the wild as it were, no owner, so may be null.

References(x => x.Owner)
    .Column(nameof(Vehicle.Owner).ToLower() + ColumnNames.Id)
    .Nullable();

MotorVehicleDivision side of things, the mapping is, AllDeleteOrphans is correct here, I believe, if for any reason an MVD instance goes away, should pull all the Vehicle objects along with it:

HasMany(x => x.Vehicles)
    .Inverse()
    .OrderBy(x => x.VehicleIdentificationNumber)
    .Cascade.AllDeleteOrphan();

Owner side is a bit trickier, if Player goes away for any reason should leave Vehicle intact, so we simply Refresh, I think, Inverse as well, of course.

HasMany(x => x.Vehicles)
    .Inverse()
    .Cascade.Refresh()
    .Table(JoinNames([TableNames.efcore, TableNames.wbe, nameof(Vehicle).ToLower()]));

Having some difficulty saving, somewhere along the way the relationships are being dropped and the transaction is rolling back.

Anyone better versed in this sort of mapping, perhaps, any insights?

Initially I thought perhaps a many-to-many joining table, however, this is really overkill, Vehicle cannot have multiple owners, so the next best shot at it, is this, I think.

Internally we respond with appropriate collections, observability, and so forth, to ensure that the properties are properly affected prior to SaveOrUpdate.

I am getting an error: NHibernate.ObjectDeletedException: 'deleted object would be re-saved by cascade (remove deleted object from associations)[WhalleyBotEnhanced.Player#xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx]'.

Saving is properly contained in a try catch and transacted so I get commits and rollbacks "for free" as part of that callback. I've verified that much of the repository pattern works, just having a bit of difficulty persuading the one and a half parents (MVD the true parent, Owner being 'parent' but may be null).

Any ideas how to better approach this one?

Thanks!

[mwpowellhtx]

Postgres table structure wise, both columns motorVehicleDivisionId and ownerId are appropriately measured as foreign keys, ownerId of course can be NULL.

My guess is something about the Cascade in the mapping is not especially kosher with the use case. Is there a better method of cascading I could be using, or perhaps none at all?

It is possible for a Vehicle in the wild to not have any owner whatsoever, which I think is part partial what may be happening.

HasMany(x => x.Vehicles)
    .Inverse()
    .Cascade.Refresh()
    .Table(JoinNames([TableNames.efcore, TableNames.wbe, nameof(Vehicle).ToLower()]));

[mwpowellhtx]

The database logs do not show any corresponding INSERT behaviors, and is trying to instead SELECT all of what I think are the 100+ vehicles records. So something is obviously breaking down in one of the HasMany() or References(), though I'm not sure exactly what at the moment.

Full thrown exception:

0: OnSave: NHibernate.ObjectDeletedException: deleted object would be re-saved by cascade (remove deleted object from associations)[WhalleyBotEnhanced.Player#xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx]
0: OnSave: NHibernate.ObjectDeletedException:    at NHibernate.Impl.SessionImpl.ForceFlush(EntityEntry entityEntry)
   at NHibernate.Event.Default.DefaultSaveOrUpdateEventListener.EntityIsTransient(SaveOrUpdateEvent event)
   at NHibernate.Event.Default.DefaultSaveOrUpdateEventListener.PerformSaveOrUpdate(SaveOrUpdateEvent event)
   at NHibernate.Event.Default.DefaultSaveOrUpdateEventListener.OnSaveOrUpdate(SaveOrUpdateEvent event)
   at NHibernate.Impl.SessionImpl.FireSaveOrUpdate(SaveOrUpdateEvent event)
   at NHibernate.Impl.SessionImpl.SaveOrUpdate(String entityName, Object obj)
   at NHibernate.Engine.CascadingAction.SaveUpdateCascadingAction.Cascade(IEventSource session, Object child, String entityName, Object anything, Boolean isCascadeDeleteEnabled)
   at NHibernate.Engine.Cascade.CascadeToOne(Object parent, Object child, IType type, CascadeStyle style, Object anything, Boolean isCascadeDeleteEnabled)
   at NHibernate.Engine.Cascade.CascadeAssociation(Object parent, Object child, IType type, CascadeStyle style, Object anything, Boolean isCascadeDeleteEnabled)
   at NHibernate.Engine.Cascade.CascadeProperty(Object parent, Object child, IType type, CascadeStyle style, String propertyName, Object anything, Boolean isCascadeDeleteEnabled)
   at NHibernate.Engine.Cascade.CascadeCollectionElements(Object parent, Object child, CollectionType collectionType, CascadeStyle style, IType elemType, Object anything, Boolean isCascadeDeleteEnabled)
   at NHibernate.Engine.Cascade.CascadeCollection(Object parent, Object child, CascadeStyle style, Object anything, CollectionType type)
   at NHibernate.Engine.Cascade.CascadeAssociation(Object parent, Object child, IType type, CascadeStyle style, Object anything, Boolean isCascadeDeleteEnabled)
   at NHibernate.Engine.Cascade.CascadeProperty(Object parent, Object child, IType type, CascadeStyle style, String propertyName, Object anything, Boolean isCascadeDeleteEnabled)
   at NHibernate.Engine.Cascade.CascadeOn(IEntityPersister persister, Object parent, Object anything)
   at NHibernate.Event.Default.AbstractFlushingEventListener.CascadeOnFlush(IEventSource session, IEntityPersister persister, Object key, Object anything)
   at NHibernate.Event.Default.AbstractFlushingEventListener.PrepareEntityFlushes(IEventSource session)
   at NHibernate.Event.Default.AbstractFlushingEventListener.FlushEverythingToExecutions(FlushEvent event)
   at NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent event)
   at NHibernate.Impl.SessionImpl.Flush()
   at NHibernate.Impl.SessionImpl.FlushBeforeTransactionCompletion()
   at NHibernate.Impl.SessionImpl.BeforeTransactionCompletion(ITransaction tx)
   at NHibernate.Transaction.AdoTransaction.Commit()
   at WhalleyBotEnhanced.Repositories.Repository.Transact(Action`2 action) in L:\Source\SCUM\WhalleyBotEnhanced\wbenhanced-proto\src\WhalleyBotEnhanced.Data.Persistence\Repositories\Repository.cs:line 48
   at WhalleyBotEnhanced.Repositories.Repository.SaveOrUpdate(IReadOnlyCollection`1 entities, Boolean transact) in L:\Source\SCUM\WhalleyBotEnhanced\wbenhanced-proto\src\WhalleyBotEnhanced.Data.Persistence\Repositories\Repository.cs:line 192
   at WhalleyBotEnhanced.Repositories.Repository.SaveOrUpdate(Object entity, Boolean transact) in L:\Source\SCUM\WhalleyBotEnhanced\wbenhanced-proto\src\WhalleyBotEnhanced.Data.Persistence\Repositories\Repository.cs:line 79
   at WhalleyBotEnhanced.Models.WhalleySessionViewModel.OnSave() in L:\Source\SCUM\WhalleyBotEnhanced\wbenhanced-proto\src\WhalleyBotEnhanced.Wpf\Models\WhalleySessionViewModel.cs:line 386

[mwpowellhtx]

Well here's a hair brained crazy idea... And I've got something similar already in Squad entities, I introduce effectively a Zero or Null Squad use case, when Player is effectively solo, for data modeling purposes. So instead of perhaps allowing Owner to be null, could default to a Null or Zero Player, perhaps, indicating non-Owner owner. Assuming of course this is the issue fouling up the works.

[mwpowellhtx]

I am starting to wonder if perhaps in the case of an optional null or instance HasOne is more appropriate. Whereas MotorVehicleDivision really does need to be the Reference. How would that work though... HasOne (nullable?) from the Vehicle side, Owner (Player) side, HasMany, still?

[mwpowellhtx]

Got some updates here, and I think perhaps it may be rooted somewhere in our API reconciliation algorithms, half a dozen or so, several of which potentially impact squads, players (three or four alone, for different things), vehicles, and so forth.

Reconciling from upstream API response is usually a three step process. Update the existing instances, add new instances, and remove non-existing instances, after basically taking some set intersections between respective dictionary ids. So bare minimum the API recon needs to also include the zero instances, as this is internally manifested for consistency sake.

...

Again back to the indication of, "1-many having some precedence issues" ... Or at least what seems to be precedence issues. Initiially I thought perhaps I might need to introduce some joining tables in order to allow root entity instances to be able to save or update persistently, before thinking about their respective joining relationships.

In most cases, I have a root entity T which may have zero or more of another entity U. So to this point I have a U.T property when I need to call back to the 'owner instance'. Does it make sense?

High level, 10K meter view, I have these, arrows indicating generally having many of a thing.

server
-> squads -> members (players)
-> players -> squad
-> mvd -> vehicles -> owner (player)

High level, multiple squads can appear on a server, as can multiple players. Generally, I have the source table mapped, having many of a constituent collection. Then I also have usually a reference mapped, in most cases to at least server, in the case of players, also a squad reference; and in the case of vehicles, also an owner (player) reference.

I am getting exceptions kicked back to me indicating some issues with transient instances during save or update. And inspecting the references, relationships, I'm not sure how better to negotiate the mapping.

I start with a default 'null instance' basically 'zero' for constitient ids which we use to identity 'ghost' or a unaligned squad and/or player instance. All unaligned players are members of the zero squad; and all wild (not owned) vehicles 'belong' to the zero player. We do this for referential consistency throughout, it just makes sense to do that.

I think we have sort of a chicken before the egg issue going on somehow, not sure how better to train the fluent mappings to prefer one entity persistence before the next.

// in this case, we get the following exception thrown.
not-null property references a null or transient value WhalleyBotEnhanced.Player.Squad

And indeed there are 10, 4, 134 transient, players, squads, vehicles, respectively. This is all we get from the exception message, nothing as far as I can tell in the database logs. So best guess either player and/or squad in question, or the reference therein, is somehow transient, player to squad, before the squad having been persistent.

//// From debugger sourced feedback. default(ulong) for the zero instance.
// 0: players.Where(x => x.SteamId == default(ulong)).ToArray()
// 0: squads.Where(x => x.SquadId == default(ulong)).ToArray()
// 134: vehicles.Where(x => x.Owner?.SteamId == default(ulong)).ToArray()
// !!! 7: players.Count(x => x.Squad?.SquadId == default(ulong))

And indeed there are some "unaligned" or "individual" players, which squad is not among the squads to be saved or updated.

Maybe there is also a better way to introduce joining tables such that the source entities are allowed to persist unimpeded, apart from the 'root parent-child' reference, if you will; by associated references, then to persist those joins. I don't think there are any properties associated with the joins, per se, so perhaps the 'vanilla' (fluent) nhibernate joining protocols would be adequate in this case.

I also need to double check, there are half a dozen or so API conversations going on in which I may also be inadvertently dropping "non-existing" ids, either squad, or player, in which for instance id is 'zero'. In other words thos need to also respect the zero instance, allowing that to persist as well. Is probably the simplest thing to verify what is going on.

Any ideas?

Would be great if there were a discord, or at least more engagement here, or via github discussions, perhaps.

Thank you...