And the brilliant thing is, the hydration, especially of cached instances,
"just works", verifying some relationships, object IDs in debugger, etc.
The joins and relationships are all there like I wanted, etc. Unlike the
nearest competitors in EF, in which apparently you have to start doing
nonsense like exposing model Ids and such, get into DTO projections
needlessly, or whatever.
On Friday, June 6, 2025 at 5:32:45 PM UTC-4 Michael W Powell wrote:
> Have achieved a minor bit of success, and better comprehension of the
> dealings with mapped many collections. Yes that seems to be the case, just
> receive the collection for the most part as is from the NH hydration
> sources. Can initialize it to [] if necessary when null, but otherwise,
> leave it be, and introduce the sister ObservableCollection<T> for handling
> the model bidirectional aspects.
>
> On Friday, June 6, 2025 at 2:49:54 PM UTC-4 Michael W Powell wrote:
>
>> I have sort of resolve the issue by adding KeyColumn, but now getting
>> another hairy issue, I think possibly on how I am dealing with model
>> collections.
>>
>> HasMany(x => x.Teams)
>> .KeyColumn("leagueId")
>> .Cascade.AllDeleteOrphan();
>>
>> {"A collection with cascade=\"all-delete-orphan\" was no longer
>> referenced by the owning entity instance:
>> WhalleyBotEnhanced.Console.Spike.Models.MyLeague.Teams"}
>>
>> In my model collection member property setters, I receive IList<T> and
>> wrap it in an ObservableCollection<T>.
>>
>> However, scanning some SO and other blogs, this may not ba a kosher thing
>> to want to do with NH or Fluent, which IIRC, makes sense.
>>
>> For improved model observability, perhaps want to have a sister internal
>> observable collection handling that aspect. Which handles the bidirectional
>> aspects, setting and nullifying of parents and what not.
>>
>> Does this pattern sound familiar to anyone? Sound about right? I cannot
>> imagine this is that uncommon of a scenario, quite honestly.
>>
>> Cheers, best!
>>
>> Michael
>>
>> On Friday, June 6, 2025 at 2:08:16 PM UTC-4 Michael W Powell wrote:
>>
>>> Hello,
>>>
>>> I have the following log, but first my fluent references setting cascade
>>> save or update, which that navigation seems to be resolving nearly as
>>> expected (except for 'column'). Collections has many setting cascade all
>>> delete orphan.
>>>
>>> From the logs as you can see the save or update does appear to be
>>> walking the tree correctly.
>>>
>>> Roster is intended to be a joining table between Team and Player. I do
>>> not see anywhere that I have not defined somehow "leagueId" with respect to
>>> "team", but perhaps I am missing something, a Column(...) or a
>>> ForeignKey(...) something or another.
>>>
>>> 2025-06-06 13:51:36.359 EDT [40432] LOG: statement: BEGIN TRANSACTION
>>> ISOLATION LEVEL READ COMMITTED
>>> 2025-06-06 13:51:36.361 EDT [40432] LOG: execute <unnamed>: select
>>> myleague0_.Id as id1_2_ from public.spike_nodatime_league myleague0_
>>> 2025-06-06 13:51:36.476 EDT [40432] LOG: execute <unnamed>: INSERT INTO
>>> public.spike_nodatime_league (Id) VALUES ($1)
>>> 2025-06-06 13:51:36.476 EDT [40432] DETAIL: parameters: $1 =
>>> '90ac98f6-a8a1-4822-98cd-b2f401265355'
>>> 2025-06-06 13:51:36.479 EDT [40432] LOG: execute <unnamed>: INSERT INTO
>>> public.spike_nodatime_team (leagueId, Id) VALUES ($1, $2)
>>> 2025-06-06 13:51:36.479 EDT [40432] DETAIL: parameters: $1 =
>>> '90ac98f6-a8a1-4822-98cd-b2f401265355', $2 =
>>> '9afe121c-d45b-48fc-9d0a-b2f40126535b'
>>> 2025-06-06 13:51:36.481 EDT [40432] LOG: execute <unnamed>: INSERT INTO
>>> public.spike_nodatime_player (leagueId, Id) VALUES ($1, $2)
>>> 2025-06-06 13:51:36.481 EDT [40432] DETAIL: parameters: $1 =
>>> '90ac98f6-a8a1-4822-98cd-b2f401265355', $2 =
>>> '72ccde8c-7460-4401-bfcb-b2f40126535c'
>>> 2025-06-06 13:51:36.483 EDT [40432] LOG: execute <unnamed>: INSERT INTO
>>> public.spike_nodatime_roster (teamId, playerId, Id) VALUES ($1, $2, $3)
>>> 2025-06-06 13:51:36.483 EDT [40432] DETAIL: parameters: $1 =
>>> '9afe121c-d45b-48fc-9d0a-b2f40126535b', $2 =
>>> '72ccde8c-7460-4401-bfcb-b2f40126535c', $3 =
>>> 'a5c3142b-ee86-43c7-abdd-b2f40126535b'
>>> 2025-06-06 13:51:36.488 EDT [40432] ERROR: column "myleagueid" of
>>> relation "spike_nodatime_team" does not exist at character 39
>>> 2025-06-06 13:51:36.488 EDT [40432] STATEMENT: UPDATE
>>> public.spike_nodatime_team SET MyLeagueId = $1 WHERE Id = $2
>>>
>>> Best, thank you,
>>>
>>> Michael W. Powell
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fluent-nhibernate/4ad53cfe-6bb0-4ff1-9c7c-6867bf0187f3n%40googlegroups.com.
