Re: [Modeling-users] Couple of questions...

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

Mario Ruggier <ma...@ru...> wrote:
> > Almost... because EXISTS applies to a independent subquery, while the o=
ther
> > keywords are constraints on the current query. Would this be a possible=
 source
> > of confusion?
> >=20
> > What happens if we intermix these keywords, e.g.
> >=20
> > ec.fetch('Writer', 'books.publisher.numPages>50
> > AND (books.publisher.bizName IN ["P1","P2"])
> > AND NOT EXISTS(books.publisher.bizName NOT IN ["P1","p2"] ) '
> >=20
> > to get the authors that have books with at least 51 pages as well as ha=
ving
> > published with both of P1 and P2 but with no one else. Would this work?=
 There
> > would be a simpler way to do this?

> oops, sorry, just realized that's pretty silly. Lousy example...
> Make that something like:
>=20
> ec.fetch('Writer', 'books.publisher.numPages>50
> AND (books.publisher.bizName IN ["P1","P2"])
> AND NOT EXISTS(books.publisher.country NOT IN ["c1","c2"] ) '
>=20
> or so...

Not a problem:) My idea of this is that everything should nicely play
one w/ the other, or we'll lose most of the feature, so we should be
able to intermix every keyword w/o problem. I'll play with this some
day for sure. To be more precise, in our case (a fetchspec) EXISTS do
apply to an independent query but this query is always bound to the
original one: look at this:

  =3D# SELECT DISTINCT t0.ID, t0.LAST_NAME, t0.FIRST_NAME, t0.AGE,
  -#                 t0.FK_WRITER_ID, t0.BIRTHDAY
  -# FROM WRITER t0
  -# WHERE NOT EXISTS (SELECT * FROM BOOK,WRITER,PUBLISHER
  (#                   WHERE WRITER.ID=3Dt0.ID
  (#                         AND WRITER.ID=3DBOOK.FK_WRITER_ID=20
  (#                         AND BOOK.FK_PUBLISHER=3DPUBLISHER.ID
  (#                         AND PUBLISHER.BIZ_NAME!=3D'P1');

the second WHERE clause binds the "independent query" to the first one
with WRITER.ID=3Dt0.ID.

--> that's why I think this shouldn't be difficult to implement, but I
    need to experiment with nested EXISTS clause (I do not have enonugh
    sql knowledge to foresee the possible coming complications).


  BTW I'll will be mostly off for a week, not sure if I'll read email
      for that time, and I'll be back online for sure some day next
      week.

-- S=E9bastien.