I have a 1:n relationship, where then '1' side is an inheritance hierarchy.

If I load a collection of the 'n' side and then reference the '1' side, how can I make it use a polymorphic fetch? Currently, when it does a lazy load it loads in the abstract base type?

Is that right? Seems like it would do a polymorhpic fetch.

I was doing this...

MyNSideEntityCollection NSideColl = new NSideColl(); NSideColl.GetMulti(null); NSideColl[1].Some1SideHierarchyEntity.Fields['SomeInheritedFieldThatShouldBeThere'] and getting an error...

If Some1SideHierarchyEntity is in a hierarchy, then yes, the fetch is polymorphic. Please post more info about the error (message and stack trace). Also the version, RTL version and generated SQL (http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7725).

Ok, well I was getting an error when doing Fields['Side1']. Let me setup a test and double check everything - now that I know it IS supposed to polymorphic.

I thought I had seen this work before and now I think I see the issue.

What if before you did the fetch of the 'n' collection you added a prefetchpath and relation to the 1 side - which would of course be to the ABSTRACT one.....then when it lazy loaded it would not do polymorphic I bet.

MyNSideEntityCollection NSideColl = new NSideColl(); PrefetchPath prefetch = new PrefetchPath(EntityType.MyNSideEntity); prefetch.Add(MyNSideEntity.PrefetchPath1SideEntity);

RerlationCollection relations - new RelationCollection(); relations.Add(MyNSideEntity.Relations.PrefetchPath1SideEntityUsingPKey);

NSideColl.GetMulti(null, 0, null, relations, prefetch); NSideColl[1].Some1SideHierarchyEntity.Fields['SomeInheritedFieldThatShouldBeThere']

This may force it to load the abstract one.....ugh. What I want it to do is to prefetch that relationship (because I need it for every record), but do it polymorphically....how would I set that up?

Which LLBLGen Pro runtime library version are you using?

It's a polymorphic fetch, as you can see in MyNSideEntityBase.cs, the method GetSingleSome1SideHierarchyEntity(bool). There, it calls the FetchPolymorphic method to fetch the related entity polymorphically, i.e. if a subtype is associated with the current entity instance, it will fetch that one.

As you index into the collection first, it's IMHO first a priority to check whether the entity at position '1' indeed has a subtype associated with itself. (oh, and please use real entity names next time ). Please place a breakpoint in the GetSingle... method described above to see whether it fetches things polymorphically or not.

Otis, Thanks for the reply. I built a couple of unit tests to prove my case to you and found out I was making a mistake! LOL.

I did this:

The1SideEntity.Fields[The1SideFields.CollateralDescription.ToString()]

instead of this:

The1SideEntity.Fields[The1SideFieldIndex.CollateralDescription.ToString()]

1) Curious what does a EntityField.ToString() return anyway? 2) I do not use real entity names so I do not have to do a public post (maybe others can learn). 3) You say "IMHO first a priority to check whether the entity at position '1' has a subtype.....". This is an interesting case where all sub entities have a common field, but it is not common enough to be in parent....In fact, I have a pending question about that you just replied to http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=16278

WayneBrantley wrote:

Otis, Thanks for the reply. I built a couple of unit tests to prove my case to you and found out I was making a mistake! LOL.

heh

I did this:

The1SideEntity.Fields[The1SideFields.CollateralDescription.ToString()]

instead of this:

The1SideEntity.Fields[The1SideFieldIndex.CollateralDescription.ToString()]

1) Curious what does a EntityField.ToString() return anyway?

Nothing, as it's not implemented. You should use the fieldindex enums.

2) I do not use real entity names so I do not have to do a public post (maybe others can learn).

That's understandable, but it's cumbersome to follow at times.

3) You say "IMHO first a priority to check whether the entity at position '1' has a subtype.....". This is an interesting case where all sub entities have a common field, but it is not common enough to be in parent....In fact, I have a pending question about that you just replied to http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=16278

I asked that because it might be the entity at position 1 wasn't associated with a subtype. I've seen the other post, I don't really follow what you want, but that discussion is continued there.

so when you are indexing into the Fields collection, use the fieldindex enums and cast them to an int, that's the compile time checked way to do it.

so when you are indexing into the Fields collection, use the fieldindex enums and cast them to an int, that's the compile time checked way to do it.

Absolutely! I always do that - never use strings of course! However, in this case I have to do a 'ToString()' on the fieldindex enum because the 'int position' is different in each subtype - where the fieldname is the same. Not as efficient, but does give me compile time checking.

By the way - recently I was explaining to a friend about your product and this unusual circumstance. We removed some fields from some tables. Those fields - no telling where they were used. Just unmapped them from the designer, recompiled and we were all set! (nearly - stupid ASP.NET markup uses fieldnames of course)

Thanks as always for your product and great support.

WayneBrantley wrote:

so when you are indexing into the Fields collection, use the fieldindex enums and cast them to an int, that's the compile time checked way to do it.

Absolutely! I always do that - never use strings of course! However, in this case I have to do a 'ToString()' on the fieldindex enum because the 'int position' is different in each subtype - where the fieldname is the same. Not as efficient, but does give me compile time checking.

True

By the way - recently I was explaining to a friend about your product and this unusual circumstance. We removed some fields from some tables. Those fields - no telling where they were used. Just unmapped them from the designer, recompiled and we were all set! (nearly - stupid ASP.NET markup uses fieldnames of course) Thanks as always for your product and great support.

Thanks Wayne