OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] Scan as a query type


>  I'm assuming that we're modeling  two different databases - one for
> the
> real records and one for the terms.  So the server knows based on the
> database.

No - modelling as different databases is just *one* approach, the full
list of approaches are

i) modelling as different databases (which would mean different URL
endpoints)
ii) modelling as different operations (but if possible with the same
request/response formats) on the *same* database
iii) modelling as a single operation on a single database with a
parameter indicating whether to interpret the query as a normal search
or a scan 
iv) modelling as a single operation on a single database whereby the CQL
query indicates whether this is a normal search or a scan (e.g. by using
the scan context set)

(iv) was your original suggestion of scan.index=dc.creator AND scan.term
>= <term> - I don't like this, not least of all, as the record formats
returned are now dependent on the query issued (if the query includes
the scan context set the response *must* use the scan record format)

(i) I share Ralph's concern about linking between the databases (either
via explain or a endpoint naming convention)

(iii) seems messy

So my preference is (ii)

Of course technically if we choose to continue to determine operation
via an operation parameter (ii) may be syntactically equivalent to
(iii), whereas if we move to specifying the operation as part of the URL
endpoint (ii) may be syntactically equivalent to (i) using an endpoint
naming convention!

Matthew


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]