Re: [Modeling-users] Fetching raw rows

[Sebastien B. <sbi...@us...>]

> >> Attempting, and failing, to keep up with you... ;)
> >
> > Do you mean that you tested it and it failed? I've committed today
> > afternoon slight changes, because of an unhandled situation when using
> > nested ECs. However it shouldn't have failed in a "standard" situation.
> > Could you be more explicit?
>=20
> No, did not try it. Failing -- in terms of keeping up with your dev rhyth=
m ;)

Okay... I've sometimes problem at correctly interpreting english, especially
after twilight!
>=20
> Thanks for the numbers! It helps with the overall picture of what goes on=
...
> However, just a question about the raw fetch:
>=20
> > [raw row] 1st fetch (ec empty):                0.618131995201
> > [raw row] 2nd fetch (objects already loaded):  0.61448597908
> > [raw row] 3rd fetch (objects already loaded):  2.24008309841
> ...
> >   2. You probably already noticed that fetching raw rows is
> >      significantly slower when the objects are loaded. The reason is
> >      that objects already loaded are checked for modification, because
> >      as I explained it in my previous post we have to return the
> >      modifications, not the fetched data, if an object has been
> >      modified.
>=20
> OK, i see why the 2nd fetch in this case could be significantly longer.
> But, why the 3rd? Barring any modifications to the loaded objects,
> there should not be any differences between 2nd and subsequent
> raw fetches?

Sorry, a raw copy-paste between two functions and you get the wrong message.
it should be read:

    1st fetch (ec empty)
    2nd fetch (ec stills empty)
    3rd fetch (objects already loaded)

  So you get what was explained: slower if all objects are already loaded.

> I only meant have two versions of a sample qualifier for a specific query,
> and use it in an internal test/profiling script... nothing at all for the
> public api!

  Seems like I was at least half asleep yesterday's evening!

-- S=E9bastien.