[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Issue] Need to support parameterized stored query invocation
The current strawman spec is based on the model that the client specifies a query using an abstract syntax (CQL) and the server build the concrete query by mapping the abstract CQL to the concrete syntax (e.g. SQL, XQuery etc.). Some standards such as ebXML RegRep, OGC WRS support a model where a query is implemented in the server complete with all supported predicates. Parts of the query are parameterized using paarameter variables. Clients invoke the query by simply identifying the query by its id and supplying a subset of parameters supported by the query. The server prunes the query to remove any predicate for which parameters were not supplied. In Parameterized Query there is a complete query pre-configured on the server which is pruned down to a smaller query where query parameters have been replaced with parameter values supplied by the client. Here is a brief overview of parameterized queries: * Standard queries are defined by some specification o Implementations may define non-standard queries * Server somehow implements a parametrized stored query o The query may be implemented in any syntax (or even code). Details are opaque to client o The query may be as complex or simple as needed to be o The query can easily support all kinds of joins, nested queries etc. * The query URL identifies a stored query by it id * The query URL optionally provides one or more parameters supplying name=value pairs for named parameters supported by the query * The query MUST be pre-defined in the server and cannot be constructed based on the query URL * Server may provide an interface to define new queries dynamically or allow their discovery. Open search is being considered to specify discovery of parameterized stored queries I can provide a more formal specification for Parameterized Queries later this week. CQL and Parameterized queries have different strengths, weaknesses, similarities and differences. I can highlight these later this week as well. Perhaps we should consider supporting both models in a unified way in our specification. This would meet the needs of several existing and emerging standards. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]