That raises an interesting question... Shouldn't a removed entity's reference in any of the optional association references be silently removed?? A kind of lazy GC? On Sep 6, 2015 23:26, "Paul Merlin" <[email protected]> wrote:
> Hi guys, > > Niclas Hedhman a écrit : > > I am also curious about this change; > > > > - ).distinct().forEach( unitOfWork::remove ); > > + ).distinct().collect( Collectors.toList() ).stream().forEach( > > unitOfWork::remove ); > > > > From my understanding it is the same thing (except slower). Do you recall > > what this is about? > > For other readers, this code comes from the > EntityInstance::removeAggregatedEntities method, in runtime. > > > Kent Sølvsten a écrit : > > It fixed a problem in an Aggregate test (don't recall the exact name of > > the test). > > > > My guess is that the previous version was streaming and removing > > concurrently > > - the new implementation finds all items that should be removed before > > starting the actual removal. > > I don't think there's any concurency involved here as there's no > parallel stream. > > Collecting the stream has the effect of loading all the entities in the > uow before starting to remove them. That's what the pre-streams impl did. > > Removing aggregated entities without loading them all upfront fails in > AggregatedTest because the Company's director (an Employee), is also > referenced in the 'employees' ManyAssociation. Removing the director > entity before querying/loading the employees association leads to an > exception because the employees association then references a removed > entity -> NoSuchEntityException. > > Cheers > > /Paul > >
