Re: Globally inspecting and conditionally altering fetch spec
Re: Globally inspecting and conditionally altering fetch spec
- Subject: Re: Globally inspecting and conditionally altering fetch spec
- From: Musall Maik <email@hidden>
- Date: Wed, 12 Jun 2013 19:40:52 +0200
Hi Mark,
obviously I don't have any insight in the details of your application, but if the generated SQL for joined tables is caused by modeled relationship lookups, you could perhaps include the additional qualifier part by changing your EO templates, so that foo.barArray() generally becomes foo.barArray( qualifier )?
Maik
Am 12.06.2013 um 17:47 schrieb "Morris, Mark" <email@hidden>:
> Hi Maik,
>
> We're using partitioning on most of our larger tables. Usually the root entity on any fetch spec will have a qualifier that will enable the database to make use of partition pruning. However, any of the various joined tables in generated SQL that should also be able to use partition pruning won't have the qualifier, and so performance suffers significantly.
>
> We've gotten by with solutions for specific queries, but I'm hoping to solve the general case for any generated SQL. So my thought is, check the root entity for the partitioning attribute. If it's there, check the qualifier and grab the value if it's included. If so, loop through the joined tables, checking for the attribute, and add the qualifier to the fetch spec for each one that has it.
>
> This is obviously very implementation specific, so that's another reason it would be nice if all the code involved was centralized in one spot.
>
> Thanks for taking a look!
>
> Regards,
> Mark
>
> On Jun 12, 2013, at 4:43 AM, Musall Maik <email@hidden>
> wrote:
>
>> Hi Mark,
>>
>> out of curiosity, what kind of condition are you checking the queries for?
>>
>> You already ruled out the chance to prevent those from being generated like that in the first place?
>>
>> Maik
>>
>>
>> Am 11.06.2013 um 20:59 schrieb "Morris, Mark" <email@hidden>:
>>
>>> The why is optimization. By altering the qualifier, I can greatly improve performance of these queries (say 20x).
>>>
>>> The what is just that, I need to watch for a certain class of queries, and if I see one, alter its qualifier, then let it continue processing.
>>>
>>> Thanks again!
>>>
>>> -- Mark
>>>
>>> On Jun 11, 2013, at 1:50 PM, George Domurot <email@hidden> wrote:
>>>
>>>> Well then, ya got me. I'm not sure I understand the why/what you're trying to accomplish.
>>>>
>>>> -G
>>>>
>>>>
>>>> On Jun 11, 2013, at 11:23 AM, "Morris, Mark" <email@hidden> wrote:
>>>>
>>>>> Thanks for the response! :-) Aren't those classes usually used explicitly? I'm hoping to watch every single fetch that's generated and pick and choose the ones I want to alter.
>>>>>
>>>>> -- Mark
>>>>>
>>>>> On Jun 11, 2013, at 1:18 PM, George Domurot <email@hidden>
>>>>> wrote:
>>>>>
>>>>>> You may want to take a peak at ERXFetchSpecificationBatchIterator or ERXBatchingDisplayGroup.
>>>>>>
>>>>>> -G
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jun 11, 2013, at 10:41 AM, "Morris, Mark" <email@hidden> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> If I want to check for a certain class of query, then alter the qualifier before the fetch is executed, any suggestions for the best approach? So far what I've come up with is registering for EOEditingContext.Delegate's editingContextShouldFetchObjects, then performing the fetch from there if the fetch spec matches my conditions.
>>>>>>>
>>>>>>> Thanks for any advice!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mark
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden