Subject: CAP: Badly formed SQL

From: Alan Davies <[email-masked]>
Date: Wed, 09 Jan 2002 18:09:36 -0500

I may be missing something, but this example doesn't
look like a well-formed SQL query, as the tables
(components) selected from are not joined, and VALARM
does not appear in the 'from' clause.

6.2.4.5 "search" Command
[...]
C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID,VALARM.*
C:    FROM VEVENT,VTODO
C:    WHERE VALARM.TRIGGER >= '19990310T080000Z'
C:    AND VALARM.TRIGGER <= '19990310T190000Z'
C:    AND METHOD IS BOOKED

I'm also not sure about selecting from both VEVENT
and VTODO in a single statement like this, without
worring about some complex joins or qualifying the
properties with the component that they belong to.

My suggestion is something along these lines, with
a similar query for VTODOs:

C: QUERY:SELECT DTSTART,DTEND,SUMMARY,VEVENT.UID,VALARM.*
C:    FROM VEVENT,VALARM
C:    WHERE VALARM.TRIGGER >= '19990310T080000Z'
C:    AND VALARM.TRIGGER <= '19990310T190000Z'
C:    AND METHOD = BOOKED
C:    AND VEVENT.ALARMID = VALARM.UID

--Alan

---

From: Doug Royer <[email-masked]>
Date: Wed, 09 Jan 2002 17:06:44 -0700

Alan Davies wrote:

YES - we have a commited expert :-)

> properties with the component that they belong to.

Good point, lets remove VTODO from the example or
split it into two examples.

> C:    AND VEVENT.ALARMID = VALARM.UID

I am confused, what is the 'VEVENT.ALARMID' ?
Are you proposing that the VALARM be a 'virtual table' tied
to its containing component by 'ALARMID'?

---

From: Alan Davies <[email-masked]>
Date: Thu, 10 Jan 2002 12:22:00 -0500

>to its containing component by 'ALARMID'?

Sorry, that was me making it up as I went along to look
more SQL-like. I was modelling the VALARM as being in a separate
'table' to the VEVENT, when iCalendar models VALARM as a
sub-component of VEVENT.

If we model iCalendar components as tables for our SQL syntax,
how should we express sub-components, as I can't see how
we can model a 'sub-table' in SQL92?

In the examples we've given so far, it's 'obvious' to us what
is meant by the query in each case, but if we violate the
semantics enforced by using SQL92, will we quickly run into
problems as our queries become more complex?

--Alan