Skip to main content
Jump to: navigation, search

Cosmos Architecture Meeting 5-June-08

These are the minutes for the Architecture Meeting for 6/5/08.


  • Jack
  • Ali
  • Bill
  • Sheldon
  • Mark
  • Paul
  • Hubert
  • David


Meeting Minutes

CMDBf query to SQL Mapping

path query sql and xpath are not equvalent ....

Hubert comment -- CMDBf can embed xpath expressions. I have a concern how CMDBf can be adopted by adopters that want to map the cmdbf query language to another language such as SQL. There seems to be a gap in the CMDBf spec that deals with mapping.

Bill comment -- peopled don't want to learn another query language.

Mark comment -- We should get with mark and marv to look at our design and detemermine if this would help CDMBf adoption. There is hole in how we epect how people will implement the spececificaiton

Bill comment -- We should propose propose to have a SQL pass through similar to the xpath passthrough in the CMDBf spec. There's a ton of sql builders avaiable.

Hubert comment -- The spec treats xpath as a first class citizen.

Mark comment -- I suspect that the CMDBf folks already considered a SQL passthrough. There may be concerns that this will expose to much of the database schema. You reveal alot of the structure. If we provide this function how far to we go? We are taking alot on to simplify stuff. We need to determine if this is a signification use case to adopt cmdbf.

I want to get mark and marv on board and make sure that the design is legit. We need to make sure we clearly articulate the design for the benefit of the community. How it solves this problem. The last thing we want to do is do a lot of work that will not be adopted.

Bill comment -- We could step back from cosmos point view and create documents for best practices. Create a document for analogy purposes( CMDBf query SQL mapping page). We can have the table on the front page. Another peice of the document would be the data type mapping, relation operators and how to plugin apis.

Mark comment -- From there we can figure out what kind of handlers are needed to make the implmenetation easy. I have concern trying to do too much

Ali comment -- At some point we need the framework code to back it up

Hubert comment -- We don't have a framework code.. we have a framework that Ali started (handler stuff)

Bill comment -- The most usefull part was the transformation..

Hubert comment -- ppl can easily take this(small piece of the framework). The transformation part does not provice much value(limited value). This is a common software problem.

Mark comment -- We need to understand (had discussion with aperi) whether we hit existing apis or the database tables.

Bill comment -- For Aperi we're using a hybrid approach.

Bill comment -- It would be nice if we can enhance the wizard. Right now, when your done with wizard you're scratching your head what code should be implemented in the methods. It would be nice if you knew you had a sql backend. During the wizard processing you can point to the database. The wizard would displays the database tables and allows the user to select the tables they're interested in. Right out of the box you can generate an mdr with an existing database. We can get the user along the path to create a full mdr.

Next Steps

  • Spend time to organize the use case. We will review the use case during the Summit next week.
  • On June 17th we will demo the use cases(show and tell) - Paul to coordinate with Ruth, David to coordinate with ruth a webex or emeeting.
  • Bill and Hubert
    • Need to involve mark and marv to flush out some details
    • First have a conversation with mark and marv. Maybe have a quick call to review page then regroup.
    • start an email thread with mark and marv
    • we want to hammer how do we envision the primary use case of mdr (is it SQL or use APIs)

Back to the top