STI eager loading bug

hi,

thanks for the patch in the latest nightly build - allowed us to get back up and repro our original problem - which is detailed here.

repro attached, not sure why it happens (apart from the fact the model is a bit complicated - sorry). perhaps it's the common backreference name (from both EntityC and EntityD downwards).

i suspect this bug has been around for a long time (forever?), it's just now we've added more entities to one (STI) side of the model which means we're exercising the eager load enough to notice the large amounts of sql now being executed.

also not sure of workaround apart from disabling eager loading for one side of the model - if you disable eager loading from entityC to entityX then tests pass. changing the name of the backreference or collection on one side of the STI tree doesn't help.

thanks justin

btw, apart from why on earth we've got this style of inheritance going on in the model (it seemed to make sense at the time), it may be worth noting that the designer did give us a error when we tried to use the same db column ("EntityZId") for both sides of the model.
It seemed happy enough though when we gave both those 1-many relationships (EntityC - EntityX and EntityD - EntityW) their own db columns to play with.

Hi Justin,

The reason you are seeing EntityX's being loaded is because when we perform eager loading we examine the flattened set of associations for the entity (or its base in the case of inheritance). Because EntityD is based on EntityA the flattened set includes all derivatives of EntityA which includes EntityC. There is an EagerLoad from EntityC to EntityX which is why you see the second set of EntityZ's being included in the eager load chain.

You can turn off the eager load on EntityC->EntityX to see this in action.

Similarly you have an assertion that EntityXId shouldn't be seen in the query, however EntityXId is part of the flattened set of properties on EntityA so this is why you are seeing it loaded despite it not being used in practice.

Jeremy

ok - thanks for looking at it. i retract the use of "bug". :)

i understand the behaviour as described although it was a surprise - i hadn't realised you flatten out the associations from the base.
when loading an entity that is partway down an inheritance chain i was expecting eager loads to be determined from that entity down through the inheritance hierarchy, not from the base upwards.

anyhow, i guess the fix for this is simply to use named aggregates to control the eager loading behavior. cheers

so i'm still having problems with this.

even apart from the additional unexpected queries (which i could live with), when eager loading exists on the LH side of the model LS is throwing an exception:

 Mindscape.LightSpeed.LightSpeedException: Path component [VerySeriousIncidents] not found in type [Animal]
 at ..ƒ(IdentifierExpression , Int32 , Boolean& )
 at ..ƒ(LiftedPathExpression )
 at Mindscape.LightSpeed.Querying.LiftedPathExpression.ƒ[T]( )
 at ..ƒ(AliasedTypeModel , QueryExpression , Order , Group , String , Boolean , Boolean )
 at ..ƒ(LightSpeedContext , List`1 , QueryExpression , Order , Group , String , Boolean , Boolean )
 at ..ƒ(LightSpeedContext , AliasedTypeModel , QueryExpression , String , Boolean )
 at ..ƒ(LightSpeedContext , List`1 , QueryExpression , Order , Group , String , Boolean , Boolean )
 at ..ƒ(LightSpeedContext , AliasedTypeModel , QueryExpression , String , Boolean )
 at ..ƒ(LightSpeedContext , List`1 , QueryExpression , Order , Group , String , Boolean , Boolean )
 at ..ƒ(List`1 , Query , String , IdentifierExpression )
 at ..ƒ(AliasedTypeModel , Query , String , IdentifierExpression )
 at ..ƒ(TypeModel , Query , IList )
 at ..ƒ(Query , TypeModel , IList )
 at ..ƒ(Query , IList )
 at Mindscape.LightSpeed.UnitOfWork.Find(Query query, IList results)
 at Mindscape.LightSpeed.UnitOfWorkBase.Find(Query query)
 at Mindscape.LightSpeed.Entity.LoadCollection(IEntityCollection , Entity )
 at Mindscape.LightSpeed.Entity.Get[TEntity](EntityCollection`1 entityCollection)
 at lsrepro.Inspector.get_VerySeriousIncidents() in D:\Libraries\lsrepro\lsrepro\lsrepro\model.cs:line 412
 at lsrepro.when_traversing_collection_which_has_eager_loading_up_from_abstract_base.<.ctor>b__2() in D:\Libraries\lsrepro\lsrepro\lsrepro\ReproTest.cs:line 91
 at Machine.Specifications.Catch.Exception(Action throwingAction)

i've attached another repro, this time with more reasonable entity names.

basically it all hinges on the eager loading on the DomesticatedAnimal -> Genus relationship. If that eager load is set to true (regardless of whether there is a named aggregate or not) then LS blows up trying to construct the query.

i'm actually stuck at the moment - i don't want to entirely lose the ability to eager load (even trying to control with named aggregates) which it appears is the case. but I don't think the scenario shown is particularly crazy/complex.

thanks,
justin!

Hi Justin,

Sorry for the delay on this. Ive added a fix which will be in tonights nightly build which should address this. We would now be considering if the association is within the same logical branch of the type hierarchy before checking it which removes the need to check it in the scenario above. This makes your test pass so let me know how it goes with your actual system :)

This may also fix up some of the other things we previously talked about at the same time but I have not gone back to check that at this stage.

Jeremy