Re: CAP 10: CREATE Command and ordering of responses.

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

I replied on 02/20/2003 05:56:20 PM
> > The reason multiple QUERYs were added was so that you could get
all BOOKED
> > entries for a date range and all UNPROCESSED entries in one round
trip.
> >   ~Something~ like:
> > 
> >    QUERY:SELECT * FROM VAGENDA WHERE <...date range...>
> >           AND STATE() == 'BOOKED'
> >    QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
> > 
> > It avoided two round trips for what was thought to be
> > a common 1st query after authentication.
> 
> If I can craft the EXACT same logical query using: 
> 
> BEGIN:VQUERY 
> QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE()
== 'BOOKED'
> END:VQUERY 
> BEGIN:VQUERY 
> QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
> END:VQUERY 
> 
> with no apparent justification for this then I call this 
> overengineering it.   Lets simplify the design to avoid "Well
I did 
> it this way only since the spec says I can.  I dont care if you
only
> designed your product to do it only another way! kinds of 
> discussions we will eventually run into otherwise. 

I should note here that I do NOT disagree
w/Dougs described case; it is prefectly normal and reasonable.  However
it does not factor in that the data set of results does NOT overlap.  The
current draft has no mention on the the sole expected behaviour is for
the case where QUERYs result in overlapping results.  This is what
Andrea and I have been trying to point out as needing some more polish.

All we want is there to be some explicit
description for the behaviour when the results do overlap so we get consistant
results no matter the implementation.  There, I hope that clarifies
the issue.  Now I still think that my suggestion of returning 1 result
per matching unique entry is the way to go.  Is there another way
to achieve the same clarity?  Im all ears...

Bruce 
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...