Improving polymorphic fetch performance.

Posts   
 
    
nottinbe
User
Posts: 46
Joined: 15-Mar-2007
# Posted on: 06-Dec-2007 23:01:53   

Using adapter, 2.5.7.1119

I have an Order table, and several derived tables such as OrderTypeA, OrderTypeB, etc. They are setup with a 1:1 relationship between OrderID.

For a given database, the code will be able to know that there would never possibly be certain order types. In many cases, out of the many order types that there will be, every order in the system will be known to be of the same known type.

What can I do in code to tell the LLBLGen polymorphic fetch system not to bother LEFT JOIN'ing to the tables that I know will not have any rows?

Thanks, Brian

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 07-Dec-2007 09:52:32   

So if you have Order table, OrderTypeA, OrderTypeB and OrderTypeC.

Do you want to fetch all Orders, without fetching the OrderTypeC? In this case I think you can filter it out by using a TypeFilter as follows:

filter.Add(!OrderTypeCEntity.GetEntityTypeFilter());

Note the negation used "!".

Or do you want to fetch one type like OrderTypeA? Because then you may fetch it explicitly without the polymorphic fetch of all Orders.

nottinbe
User
Posts: 46
Joined: 15-Mar-2007
# Posted on: 07-Dec-2007 14:59:08   

Given certain configuration, I may know that there would exist some subsite of OrderTypeA, OrderTypeB, and OrderTypeC. It may be only one, it may be all, or anywhere in between.

I should probably just try it and see, but I'll ask anyway - Using the negated GetEntityTypeFilter(), what that does is make LLBLGen not try to LEFT JOIN that table in the SELECT query?

Thaks, Brian

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 07-Dec-2007 16:27:19   

You have posted your last question in details in a new thread. http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12092 I'll close this one so we can follow up in one place.

nottinbe
User
Posts: 46
Joined: 15-Mar-2007
# Posted on: 07-Dec-2007 16:31:19   

No, that thread is a different question. In that thread, I am saying that in that case since I am requesting only a specific result field that is not in a leaf table, that LLBLGen should know not to do the LEFT JOIN on its own. I'm saying I feel its a bug that its doing the LEFT JOIN in that case.

In this thread, I am saying that when doing a polymorphic fetch using FetchEntityCollection, where I DO expect LLBLGen to do the LEFT JOIN, that I want a way to explicitly tell it what tables NOT to LEFT JOIN on since I know they will have no rows.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 07-Dec-2007 17:10:57   

That's not supported. Also, do you really want to? The thing is: say if we have such a feature where you can specify which types not to consider. Then your app gets deployed, and then these tables DO get data. Then your app fails to work.

Frans Bouma | Lead developer LLBLGen Pro
nottinbe
User
Posts: 46
Joined: 15-Mar-2007
# Posted on: 07-Dec-2007 17:17:16   

It would specify which types not to consider dynamically, at runtime, based on the current properties\configuration of the specific deployment. Given the configuration of a particular deployment, it would be known to be impossible to have data in certain. I will end up with a lot of leaf tables. For a given deployment, 1 or 2 of them may have data. I don't want to LEFT JOIN 20+ tables when I know only 1 or 2 would ever be necessary.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 07-Dec-2007 17:19:33   

I find that an approach which has a high risk of causing problems along the way.

As I said in another thread, and what's also specified in the concepts section about inheritance: inheritance over multiple tables DOES hurt performance, due to the joins. If you don't want that, don't use inheritance.

Also, why have 20 subtypes if they won't contain any data?

Frans Bouma | Lead developer LLBLGen Pro
nottinbe
User
Posts: 46
Joined: 15-Mar-2007
# Posted on: 07-Dec-2007 17:24:40   

Well its not just a matter of does it hurt performance or not. Its a matter of how much it hurts performance, and that's what I am trying to determine now.

Different clients have different needs. Some will only sell OrderTypeA and OrderTypeB, others only OrderTypeG and OrderTypeF. They all need to be supported - but given an installation, only a couple will be used.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 10-Dec-2007 13:33:14   

Ok.

Still, it's undoable to determine on the client with every query ran which subtypes will be used.

Frans Bouma | Lead developer LLBLGen Pro
nottinbe
User
Posts: 46
Joined: 15-Mar-2007
# Posted on: 10-Dec-2007 13:42:36   

Sorry if I misunderstand you, but when you say "determine" it sounds like you thought I wanted LLBLGen to figure out which subtypes to exclude.

For a given installation of our application, we'll know basically at install time which will be needed. So I was just hoping there was some way to manipulate the relationship collections, or the inheritance data, or whatever, on application startup that would make LLBLGen not even realize those subtypes existed.

I figured there's obviously generated code that is telling LLBLGen what subtypes exist, so there must be a way for me to write code that inspects the given application instances configuration and removes the information for those unneeded subtypes.

If there is just absolutely no way to do that, then you can just ignore this and I'll be quiet now.