Re: [Modeling-users] Fetching raw rows

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

Mario Ruggier <ma...@ru...> wrote:
> On jeudi, juil 17, 2003, at 16:43 Europe/Amsterdam, Sebastien Bigaret wro=
te:

Hey, you probably meant: "at 16:43 Europe/Paris" ;)

> > 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 ins=
erted
> >>      objects must be present, while deleted objects shouldn't be retur=
ned.
> >>
> >>   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 beha=
ve
> >>   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 relea=
se.
>=20
> 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?

> 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?

It does not matter whether the objects are already loaded or not. And
fetching raw rows does not create any object, never. When I said:

> >   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.

I meant that inserted objects should appear when a fetch for raw rows
was made (at least, if the object would appear in a normal fetch:
remember that if you insert, say, a Book, then fetch all books, you'll
get the new one along with the others --even if the new object is not
saved in the database yet. I've just added a section in the User's Guide
about this today! BTW same for deleted objects: they shouldn't appear in
the result set of a fetch (objects or raw rows).=20

  For completeness, I'll add that when a object is modified, it should
appear in its modified state in the result set.

> 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)
>=20
> 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?

I've a test db w/ 5000 simple objects, I'll try some test and
report. This could be added in the unittests, right.

> 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 ke=
ep
> an eye on this known possible bottleneck on the system.

  Sorry, I think I won't do this: we've just clarified the API, I do not
feel like splitting the fetch in two. However, what I *will* do is:

  1. document the alternate (and less cpu-consuming) way of building
     qualifiers,

  2. add a section in the user's guide dealing with performance tuning,
     and explaining this particular point among others.

I think this should be enough, isn't it?


-- S=E9bastien.