Re: [Modeling-users] Fetching raw rows

[Mario R. <ma...@ru...>]

On jeudi, juil 17, 2003, at 16:43 Europe/Amsterdam, Sebastien Bigaret 
wrote:
>
> I wrote:
>>   Okay, back to the functionality: as it is made in the patch, 
>> fetchesRawRows
>>   misses two important functionalities:
>>
>>   1. it must behave the way a normal fetch behaves. This means the 
>> inserted
>>      objects must be present, while deleted objects shouldn't be 
>> returned.
>>
>>   2. It does not work at all for nested ECs.
>>
>> I thought that those of you who are already using the patch should be
>> aware of this.
>>
>>   I'm currently working on both problems. Unittests are written, now 
>> I'm
>>   on the code itself. When integrating this into the CVS, it will 
>> behave
>>   as expected in both situations. I'll report then here.
>
>   Full functionality has been integrated in cvs yesterday evening, and 
> I've
>   completed the documentation today. All this will be in the next 
> release.

Attempting, and failing, to keep up with you... ;)

Anyhow, just a small clarification: this means that raw fetches must in 
any
case exist within an editing context? I.e if the raw fetch implies 
objects not
yet in the EC, these objects are loaded, and "CustomObject 
initialised", into
the EC?

Given the same db, what is the performance difference between
the following fetches (for logically equivalent queries)?
- 1st time "classic" fetch (in empty EC)
- 2nd time "classic" fetch (objects in resultset already known to EC)
- 1st time raw fetch (in empty EC)
- 2nd time raw fetch (objects in resultset already known to EC)
- 1st time dbapi2.0 execute query (direct via python adaptor)
- 2nd time dbapi2.0 execute query (direct via python adaptor)

It would be interesting to keep an eye on these values, for a particular
setup, thus when changes to the system are made, unexpected performance
side effects may still be observed. Maybe such a script can be added to
the tests?

And, the classic fetch may be further broken up into two, one built with
Qualifiers and the other with RawQualifiers (as per recent thread), to 
keep
an eye on this known possible bottleneck on the system.

mario