Hei.

We are using LLBLGen v5.6.0 RTM, adapter.

I am using FetchEntityCollection, including only fields from the super-most table of a hierarchy. I still get joins to all sub tables which is bad for performance.

I'd like to turn off polymorphic for my fetch. Is that possible?

If not, Linq is an option, but we have a lot of UI filter and sort event handling that needs rewriting.

So perhaps typed list is the best approach?

Thanks, Tore.

If you need the data of the root entity only, it's perhaps also an idea to map an entity onto that table separately of the hierarchy and use that entity for your fetch for this particular situation (if you need to modify the data).

If you need the data in a readonly fashion, you can indeed also map a typed view with a poco query (linq or queryspec) onto the table, which doesn't bring in the derived types when querying it.

Thanks Frans.

Good tip. I will proceed with mapping another entity on the table.

Please consider this a feature request though. It would be a lot simpler with a flag to turn off polymorphic fetch.

Ok, like a linqQuery.NoSubtypes() method? We'll see what we can do.

I was thinking a noSubTypes flag to the FetchEntityCollection method.

Yes in queryspec it will likely be that or a method on the query. Flags on the fetch methods are a bit problematic as they add a set of overloads.

We analyzed this and we decided not to add this. We had it technically working, but we ran into a usability scenario that's simply not ignoreable.

First the ambiguity: Say I have Employee<-Manager<-BoardMember. If there are 2 'Managers' in the database, and one is a BoardMember, does 'no subtypes' mean when I fetch 'managers' that the boardmembers aren't allowed? Not in this scenario, as that's the job of a type filter and that already works today. What's meant is "materialize all types as this type", so the boardmember should be materialized as a manager and the query should return 2 managerentity instances.

This technically works however it gives a problem: the 'manager' entity containing boardmember data is incomplete. Deleting it will not work, as the entity inside is actually a boardmember: the boardmember table row will throw an error due to its FK constraint. Updating likely works but in edge cases it might not (validation logic in boardmember)

We can't switch the 'manager' typed object here to a 'readonly ' object to prevent a save/delete later on.

In the case of 'we know what we're doing', it will end up somewhere where everyone has know you can't persist these entities, or better: some will perhaps cause problems. After a while people have forgotten all about it and wonder why deleting 1 of the entities crashes.

So for 'fetch' scenarios it might be ok, but an entity itself isn't the suitable type for this. A typed list with a POCO class is better. You should create a typedlist with the entity in question ('Manager' in this case) and fetch that: it's not fetching subtypes and it gives readonly data.

So I'm sorry, but your feature request won't be implemented.