Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "COSMOS CMDBf Query Processing Approach"
| Line 18: | Line 18: | ||
---- | ---- | ||
| − | |||
---- | ---- | ||
Q) Does this impact the CMDBf toolkit that david has been working on? | Q) Does this impact the CMDBf toolkit that david has been working on? | ||
Revision as of 09:25, 5 June 2008
In order to provide a common framework or design pattern to solve the problem of interpreting CMDBf queries, we need to formalize the approach in interpreting the queries.
- Each CMDBf query can be translated to one or more logical queries.
- Each partially connected graph will result in a "logical query".
- The number of logical queries equals to the number of disjoint graphs in the CMDBf query.
- Form heuristics of mappings between each logical query (in CMDBf query syntax) and the native query language. The mapping needs to be a two-way mapping. Hence some features of the either query language may not be utilized. If the logical query is expressed in a way that's outside the capability of the native query, several simpler native queries will result, and extra processing is required by the MDR to process what the backend application cannot handle. The MDR can also decide to simply reject the query without processing.
- The result sets of the native queries are combined using the UNION operation, and returned to the query client in the CMDBf query response format.
There are several classes of query languages.
- SQL (relational database)
- XPath (path queries / hierarchical data)
- calling an application API - the complexity of the query is hidden by a program interface
The mapping of query responses to CMDBf query response
- JDBC result set (or SQL result in general)
- XML
Q) Does this impact the CMDBf toolkit that david has been working on?