Subject: Re: CAP: Badly formed SQL

From: [email-masked]
Date: Thu, 10 Jan 2002 11:27:42 -0500

Doug replied:
>> 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.
>
>Good point, lets remove VTODO from the example or
>split it into two examples.

That wont resolve the issue of what would come back if someone actually 
did make that query (since it appears to be legally formatted to me). 
Granted the prose for _this_ example says "Find alarms within a range of time for booked VEVENTs." which means that the VTODOs acutally dont belong in the example. HOWEVER, 
if its possible to do then we should show a sample for it.  (Anyone care 
for some multipart/* rehashing and interpretations in iCalendar??)

Having forgotten most of the SQL I knew from my dB days I dont see that 
any joins, etc are really going to happen (or should happen).  Just 
because we use SQL-MIN does not mean we are mandating that the CS actually 
use SQL as its engine, right?? 

So, for the cited example query why wouldnt the CS just return all the 
data that match the parameters.  That is, something like:

...
S: Content-Type: text/calendar
S: Content-ID: [email-masked]
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: BEGIN:VEVENT
S: DTSTART:19990310T130000Z
S: DTEND:19990310T133000Z
S: UID:abcxyz8999
S: SUMMARY:Meet with brave Sir Robin
S: BEGIN:VALARM
S: TRIGGER:19990310T132500Z
S: SUMMARY:Almost time...
S: ACTION:DISPLAY
S: END:VALARM
S: END:VEVENT
S: BEGIN:VTODO
S: DTSTART:19990310T124500Z
S: DTEND:19990310T125000Z
S: UID:qwerty1234
S: SUMMARY:Change my armor before meeting with brave Sir Robin
S: BEGIN:VALARM
S: TRIGGER:19990310T124500Z
S: SUMMARY:Go and change your armor...
S: ACTION:DISPLAY
S: END:VALARM
S: END:VEVENT
S: END:VCALENDAR
S: --boundary-435fe--
S: END
S: NUL 1 15 . 16671 0
S: END

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked]
Still recoiling from the implants...

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 13:32:23 -0700

[email-masked] wrote:
> That wont resolve the issue of what would come back if someone
> actually did make that query (since it appears to be legally formatted
> to me). Granted the prose for _this_ example says "Find alarms within
> a range of time for booked VEVENTs." which means that the VTODOs
> acutally dont belong in the example.  HOWEVER, if its possible to do
> then we should show a sample for it.  (Anyone care for some
> multipart/* rehashing and interpretations in iCalendar??)

If you did that in SQL you would get data. It might not
be the data as sited in the text.

> Having forgotten most of the SQL I knew from my dB days I dont see
> that any joins, etc are really going to happen (or should happen).
>  Just because we use SQL-MIN does not mean we are mandating that the
> CS actually use SQL as its engine, right??

Correct - but we did agree that a person that knew SQL would
be able for form a query given our 'virtual database' mapping.

> data that match the parameters.  That is, something like:

We also agreed and it is (or used to be) in cap were it said
that each data set that was returned would be encapsulated
in a BEGIN/END VCALENDAR. So if you got the data from
10 components, you would get 10 BEGIN/END VCALENDAR objects
sorted by ...(it lists the default sort order near the SQL-MIN ABNF).