[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]