Difference between revisions of "COSMOSTPTPQuereryIntrfaceNotes"

Revision as of 02:58, 20 January 2007

Proposed initial data types are table, hierarchy, and graph. The API will return strings and object references?

Our long term goal is for the query interface to support strongly typed result sets, but the short term is based on tables. We want to implement stats and hierarchy first. The APIs will be provisional (and internal) for now. The new implementations will support coexistance with the existing EMF models.

Joe Toomey pointed out a few observations with EMF: Regardless of its warts, the object oriented EMF data models deliver a lot of value that should not be lost. He is uncomfortable with interfaces that deliver a less valuable sechema based data model because it is easier for a consumer to adopt for example, a Rose model.

The key issue is that we have conflicting goals of functionality versus performance.(Don) Marius is less clear than Joe that we require a POJO for each part of the schema. This led to the discussion of if we are promoting a programming model v. an OO model.

• We did not discuss this from the standpoint of a "service" type of model but perhaps we should (Mark W.)

We all agreed that:

• Must not expose schema as part of the API
• Must not expose the data model as part of the API

Both of the above led to great pain and discomfort in the TPTP project.

Initial design

We talked at the F2F about simple (mostly programatic) vs POJO (with or without EMF) data model, I (Marius) think that we will have something in between and we may not surface/use EMF at the instance level.

The initial set of POJO classes would be very limited and we may also include a simple generic mechanism to represent structured data (typed or untyped) similar with SDO (initially much simpler, as we may end up using SDO at some point).

Here Cosmos-DMS-All-class-diagram.gif you can find the current state of the class diagram for Cosmos data access API (DMS data management services) where most of the components will come from TPTP DMS.

For COSMOSEcliseCon2007Demo this diagram should cover the Hierarchy (we need to see if we can find a better name), Statistical and Log domains.

For COSMOSEcliseCon2007Demo the Hierarchy data will reside in SML/SML-IF files so we will provide an IDataStoreProvider for SML/SML-IF files.

The Statistical and Log data will be stored in a database and we will create an IDataStoreProvider that will be shared by both data services implemented on top of a Derby database. As the data will be the current TPTP data we will use the TPTP large resource support schema plus some new views created specifically for this DMS interactions, this will easily let us populate the data store (using TPTP workbench).

The BIRT scripted data sources defined in COSMOS-Demo-EclipseCon2007.zip will eventually use the IDataAccessController and the specific IDataService's to build the report input data.