Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cosmos-dev] Re: cosmos work


I've add the whole thread as it brings some good questions. I'll use the mailing list from now on.

I've just updated the http://wiki.eclipse.org/index.php/Image:COSMOS-Demo-EclipseCon2007.zip please use this version if you haven't tried it out yet, if you already have it setup, just redo manual step 3. from runDemo.bat with the files from the latest version of this zip.
       3. Copy all the folders from C:\COSMOS-Demo-EclipseCon2007\demo-workspace-update-20070208 into C:\COSMOS-Demo-EclipseCon2007\eclipse\demo (override all target files).


You need also to sync the org.eclipse.tptp.platform.models project with CVS.

Vsevolod, you don't need to provide any parameter, it should work as is (some defaults are used), take a look at the reports Script tab and select the Data Explorer view and look for the defined data sets (open and fetch methods) and also data accessors from org.eclipse.cosmos.examples.eclipsecon07.reports.oda project.

If you have problems with BIRT try to redownload BIRT only I've updated the URL (in the above zip file) to point to 2.2M4, for the final demo setup that should be changed once we find the right set of dependencies.

Thanks !

Marius Slavescu
IBM Toronto Laboratory, Canada
Phone: 905-413-3610





Vsevolod Sandomirskiy <vss@xxxxxxxxxxxxx>

02/08/2007 03:30 PM

To
Marius Slavescu/Toronto/IBM@IBMCA
cc
Subject
Re: cosmos work





Marius Slavescu wrote:

>
> The answer is here (you get also a pre-populated Derby database with
> log and statistical data):
> http://wiki.eclipse.org/index.php/COSMOSEclipseCon2007Demo#demo_v02


Thanks, this is very interesting. What parameters should I enter for
these two reports (cosmos-nodes.rptdesign and LogReport.rptdesign)?

>
> The simple DB design is the way to go (although it doesn't really
> matter what database schema you have it is important to be able to
> serve quickly the DMS API - the data store manager needs to handle the
> mapping from normalized form to a simple or complex schema), if you
> can take a look at what I have in that demo setup and come up with a
> DB design that can be used to build the results for
> StatisticalDataService API that would be great.
>
> My point was that we can create a simple view on top of the TPTP
> schema/data to serve that purpose.
>
> Thanks !
>
> Marius Slavescu
> IBM Toronto Laboratory, Canada
> Phone: 905-413-3610
>
>
>
>
>
> *Vsevolod Sandomirskiy <vss@xxxxxxxxxxxxx>*
>
> 02/08/2007 11:57 AM
>
>                  
> To
>                  Harm Sluiman/Toronto/IBM@IBMCA
> cc
>                  Marius Slavescu/Toronto/IBM@IBMCA, Mark D Weitzel <weitzelm@xxxxxxxxxx>
> Subject
>                  Re: cosmos work
>
>
>
>                  
>
>
>
>
>
> One alternative is that I can write a simple perl script to parse TPTP
> statistical XML file and load it into a database. This is a simple task
> if we stick to the simple db design that Harm mentioned.
>
> I don't quite understand how users (BIRT reports?) will use this API. If
> possible, I'd like to see an example or pseudo-code.
>
> Thanks.
>
> Harm Sluiman wrote:
>
> >
> > ok.
> > not only is this code internal, it should be considered to be throw
> > away if we so choose.
> >
> > It seems to me this API has to be TPTP code given we need to GA with
> > it, and COSMOS is not going to be in a position to do that in a timely
> > fashion. This implies that for now we need a preference or environment
> > switch to enable the function.
> >
> > I suggest you take the one enhancement request for this work, (and I
> > think Joe has another) and start using child defects to integrate the
> > code.
> >
> > Thanks for your time.
> >
> --------------------------------------------------------------------------
> > Harm Sluiman, STSM,  
> > phone:905-413-4032   fax: 4920  
> > cell: 1-647-300-4758
> > mailto:sluiman@xxxxxxxxxx
> > Admin : Arlene Treanor atreanor@xxxxxxxxxx  Tie: 969-2323 1-905-413-2323
> >
> >
> > *Marius Slavescu/Toronto/IBM*
> >
> > 02/08/2007 08:24 AM
> >
> >                  
> > To
> >                  Harm Sluiman/Toronto/IBM@IBMCA
> > cc
> >                  Mark D Weitzel/Raleigh/IBM@IBMUS, Vsevolod
> Sandomirskiy
> > <vss@xxxxxxxxxxxxx>
> > Subject
> >                  Re: cosmos workLink
> >
> <Notes://D25ML01/8525667400715744/38D46BF5E8F08834852564B500129B2C/68B0AEBF2B60A25A8525727C0046EE25>
>
> >
> >
> >
> >
> >                  
> >
> >
> >
> >
> > I agree and I'm on the same page.
> >
> > We just need to define those Statistical views (which later could
> > become the new schema) on top of TPTP current schema or a new schema.
> >
> > Because I've been more focused on the read side (for the COSMOS
> > scenario) I didn't had time to write a new loader for a new
> > Statistical schema, and I quickly (few hours) changed the TPTP code to
> > push the Statistical data into the Large Resource database schema (at
> > this point this seemed to me the fastest way to get real sample data).
> >
> > We still need to think how the domain model would be discovered
> > (beside the API service methods) and how can we reflect on it if
> > required, besides of providing more complex querying mechanisms.
> >
> > The current implementation by far I don't consider it final (it is
> > basically marked as internal) and also the main concepts in the API
> > needs to be reviewed and refined (for the demo they should be fine).
> >
> > Thanks !
> >
> > Marius Slavescu
> > IBM Toronto Laboratory, Canada
> > Phone: 905-413-3610
> >
> >
> >
> >
> >
> > *Harm Sluiman/Toronto/IBM*
> >
> > 02/08/2007 08:02 AM
> >
> >                  
> > To
> >                  Marius Slavescu/Toronto/IBM@IBMCA
> > cc
> >                  Mark D Weitzel/Raleigh/IBM@IBMUS, Vsevolod
> Sandomirskiy
> > <vss@xxxxxxxxxxxxx>
> > Subject
> >                  Re: cosmos workLink
> >
> <Notes://D25ML03/852569420053AB82/BD053B46B119C67A8525643000742B16/E9D174A89B2755D78525727B0079C6E8>
>
> >
> >
> >
> >
> >                  
> >
> >
> >
> >
> > I though that back in January we agreed on a schema on the white
> > board. Why would we not just use that?
> > It should be mappable as a View of the TPTP model, or any other table
> > schema.
> >
> > We keep worrying about population, and if that is a mental road block,
> > then why not just go ahead and implement an alternate event impl of
> > addYourselfInContext. We only have a very small set of statistical
> > event formats so this should be viable.
> >
> > We seem to be in this odd state of wanting to create good architecture
> > and api first, yet use existing TPTP stuff in a rush. All to create a
> > proof of concept which should not be considered a close to final
> > implementation.
> >
> > We have an event collection and delivery system, override it to put
> > the data elsewhere.
> > We have a model viewing system, modify it to read the data as a query
> > from a new data source.
> >
> > These seem to be the poc objectives that would make a useful concept
> > demo.
> >
> > Thanks for your time.
> >
> --------------------------------------------------------------------------
> > Harm Sluiman, STSM,  
> > phone:905-413-4032   fax: 4920  
> > cell: 1-647-300-4758
> > mailto:sluiman@xxxxxxxxxx
> > Admin : Arlene Treanor atreanor@xxxxxxxxxx  Tie: 969-2323 1-905-413-2323
> >
> >
> > *Marius Slavescu/Toronto/IBM*
> >
> > 02/07/2007 05:19 PM
> >
> >                  
> > To
> >                  Vsevolod Sandomirskiy <vss@xxxxxxxxxxxxx>
> > cc
> >                  Harm Sluiman/Toronto/IBM@IBMCA, Mark D
> Weitzel/Raleigh/IBM@IBMUS
> > Subject
> >                  Re: cosmos workLink
> >
> <Notes://D25ML01/8525667400715744/38D46BF5E8F08834852564B500129B2C/74685CFF5B47F1A78525727B007983D0>
>
> >
> >
> >
> >
> >                  
> >
> >
> >
> >
> > This schema is generated from the TPTP model, you are right about the
> > complexity of it , we just need to focus on getting the db view that
> > will provide us the data for the report, I'll try to have it done by
> > tomorrow.
> > You can look at the Statistical model from TPTP to get an idea of
> > where these types and relationships are coming
> >
> (http://www.eclipse.org/tptp/platform/documents/resources/models/cat3950c20c0018/cat3e68bba7012a/dgm3e43d35b01af.png).
>
> >
> >
> > I used this schema at least for the following reasons:
> >         - easy way to get real sample data by using TPTP to collect
> > and populate the database
> >         - I will probably using it in TPTP 4.4 in the first ref of the
> > DMS implementation
> >
> > For June I see a more simplified schema, derived from the DMS API (and
> > from the corresponding domain data services), which I tried to keep it
> > really simple.
> >
> > Thanks !
> >
> > Marius Slavescu
> > IBM Toronto Laboratory, Canada
> > Phone: 905-413-3610
> >
> >
> >
> >
> >
> > *Vsevolod Sandomirskiy <vss@xxxxxxxxxxxxx>*
> >
> > 02/07/2007 05:02 PM
> >
> >                  
> > To
> >                  Marius Slavescu/Toronto/IBM@IBMCA
> > cc
> >                  
> > Subject
> >                  Re: cosmos work
> >
> >
> >
> >                  
> >
> >
> >
> >
> >
> > How did you create this db schema? Do you use any tools that map EMF
> > to RDB?
> >
> > This is obviously focused on TPTP. Assume I have statistical data that
> > comes from non-TPTP agent in completely different format. How much
> > effort will I spend trying to integrate it into COSMOS?
> >
> > I don't understand this schema. For example, what links a given
> > obervation value with a creationTime?
> >
> > Marius Slavescu wrote:
> >
> > >
> > > Here is the TPTP database schema that contains also the TPTP
> > > Statistical model:
> > >
> >
> http://dev.eclipse.org/viewcvs/index.cgi/platform/org.eclipse.hyades.resources.database/scripts/CreateDatabaseAndTablesCloudscape-including-Statistical.sql?revision=1.1&root=TPTP_Project&view=markup
>
> >
> > >
> > >
> > > Here ar the tables def related with TPTP Statistical model:
> > > CREATE TABLE "SDContiguousObservation" (  "p_p" VARCHAR(255),  "id"
> > > INT NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDContiguousRepresentation" (  "p_p" VARCHAR(255),  "id"
> > > INT NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDCounterDescriptor" (  "p_p" VARCHAR(255),  "id" INT
> > > NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1)) ;
> > > CREATE TABLE "SDDescriptor" (  "p_p" VARCHAR(255),  "id" VARCHAR(255),
> > >  "name" VARCHAR(255),  "description" VARCHAR(2000),  "databaseId" INT
> > > NOT NULL PRIMARY KEY,  "parent" INT,  "parent_TYPE" SMALLINT,
> > >  "parent_Order" INT,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDDiscreteObservation" (  "p_p" VARCHAR(255),  "id" INT
> > > NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1)) ;
> > > CREATE TABLE "SDDiscreteRepresentation" (  "p_p" VARCHAR(255),  "id"
> > > INT NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDGaugeRepresentation" (  "p_p" VARCHAR(255),
> > >  "maxThreshold" INT DEFAULT 0,  "minThreshold" INT DEFAULT 0,  "id"
> > > INT NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDMemberDescriptor" (  "p_p" VARCHAR(255),  "id" INT NOT
> > > NULL PRIMARY KEY,  "representation" INT,  "representation_TYPE"
> > > SMALLINT,  "Is_EMF_Proxy" CHAR(1)) ;
> > > CREATE TABLE "SDRangeRepresentation" (  "p_p" VARCHAR(255),  "min" INT
> > > DEFAULT 0,  "max" INT DEFAULT 0,  "id" INT NOT NULL PRIMARY KEY,
> > >  "Is_EMF_Proxy" CHAR(1)) ;
> > > CREATE TABLE "SDRepresentation" (  "p_p" VARCHAR(255),  "id" INT NOT
> > > NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1)) ;
> > > CREATE TABLE "SDSampleDescriptor" (  "p_p" VARCHAR(255),
> > >  "updateFrequencey" DOUBLE PRECISION DEFAULT 0.0,  "id" INT NOT NULL
> > > PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDSampleWindow" (  "p_p" VARCHAR(255),  "id" INT NOT
> > > NULL PRIMARY KEY,  "view" INT,  "view_TYPE" SMALLINT,  "view_Order"
> > > INT,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDSnapshotObservation" (  "p_p" VARCHAR(255),  "id" INT
> > > NOT NULL PRIMARY KEY,  "memberDescriptor" INT,
> > >  "memberDescriptor_TYPE" SMALLINT,  "memberDescriptor_Order" INT,
> > >  "window" INT,  "window_TYPE" SMALLINT,  "window_Order" INT,
> > >  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDTextObservation" (  "p_p" VARCHAR(255),  "id" INT NOT
> > > NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDTextRepresentation" (  "p_p" VARCHAR(255),  "id" INT
> > > NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > > CREATE TABLE "SDView" (  "p_p" VARCHAR(255),  "name" VARCHAR(255),
> > >  "id" INT NOT NULL PRIMARY KEY,  "Is_EMF_Proxy" CHAR(1));
> > >
> > > CREATE TABLE "SDContiguousObservation_value" (  "Id" INT,  "Value"
> > > DOUBLE PRECISION,  "Order" INT);
> > > CREATE TABLE "SDDiscreteObservation_value" (  "Id" INT,  "Value" INT,
> > >  "Order" INT) ;
> > > CREATE TABLE "SDSnapshotObservation_validityMask" (  "Id" INT,
> > >  "Value" SMALLINT,  "Order" INT) ;
> > > CREATE TABLE "SDSnapshotObservation_creationTime" (  "Id" INT,
> > >  "Value" DOUBLE PRECISION,  "Order" INT);
> > > CREATE TABLE "SDTextObservation_textValue" (  "Id" INT,  "Value"
> > > VARCHAR(255),  "Order" INT) ;
> > >
> > >
> > > If you could look into creating a view for Statisitcal data that will
> > > provide only the fields that we need in the StatReport (mapped into
> > > the DMS Statistical domain
> > >
> >
> http://dev.eclipse.org/viewcvs/index.cgi/platform/org.eclipse.tptp.platform.models/src-dms/org/eclipse/tptp/platform/provisional/dms/statistical/?root=TPTP_Project)
>
> >
> > > similar with what I created for the LogReport:
> > >
> > > CREATE VIEW "LogRecord" ("logId", "id", "extensionName",
> > > "msg","creationTime","severity","location","subComponent") AS SELECT
> > > CBE1."p_p", CBE1."id", "extensionName", CBE1."msg",
> > > CBE1."creationTime", CBE1."severity", CI."location", CI."subComponent"
> > > FROM "CBECommonBaseEvent" as CBE1 LEFT OUTER JOIN "CBEDefaultEvent" as
> > > DE on CBE1."id"=DE."id", "CBECommonBaseEvent" as CBE2 LEFT OUTER JOIN
> > > "CBEComponentIdentification" as CI on CBE2."sourceComponentId"=CI."id"
> > > where CBE1."id"=CBE2."id";
> > >
> > > I'll send later today instructions and scripts on how to get the
> > > sample data into the TPTP database.
> > >
> > > Thanks !
> > >
> > > Marius Slavescu
> > > IBM Toronto Laboratory, Canada
> > > Phone: 905-413-3610
> > >
> > >
> > >
> > >
> > >
> > > *Vsevolod Sandomirskiy <vss@xxxxxxxxxxxxx>*
> > >
> > > 02/07/2007 03:31 PM
> > >
> > >                  
> > > To
> > >                  Marius Slavescu/Toronto/IBM@IBMCA
> > > cc
> > >                  
> > > Subject
> > >                  Re: cosmos work
> > >
> > >
> > >
> > >                  
> > >
> > >
> > >
> > >
> > >
> > > I can create a sample Derby database and write a little Java
> program to
> > > load statistical XML file into the database. Should I do that?
> > >
> > > Marius Slavescu wrote:
> > >
> > > >
> > > > Hi Vsevolod,
> > > >
> > > > I hope you had a great vacation!
> > > >
> > > > The source of DMS is in the src-dms folder under this project (use
> > > > anonymous instead of slavescu):
> > > >
> > > >  
> > > >
> > > > Please take a look at what we have there and send me comments or
> > > > questions and will continue from there.
> > > >
> > > > Also if you like to take a stab at how the we should model in a
> Derby
> > > > database the Statistical model, basically in the short run that will
> > > > give us a quick way to build the views on top of the current TPTP
> > > > model (I will try to generate the schema for the Statistical package
> > > > tonight).
> > > >
> > > > Thanks !
> > > >
> > > > Marius Slavescu
> > > > IBM Toronto Laboratory, Canada
> > > > Phone: 905-413-3610
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *Vsevolod Sandomirskiy <vss@xxxxxxxxxxxxx>*
> > > >
> > > > 02/05/2007 03:04 PM
> > > >
> > > >                  
> > > > To
> > > >                  Marius Slavescu/Toronto/IBM@IBMCA
> > > > cc
> > > >                  
> > > > Subject
> > > >                  cosmos work
> > > >
> > > >
> > > >
> > > >                  
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Marius, I finally have time to do something useful for cosmos.
> Can you
> > > > point me to the sources and delegate me some real task?
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > --------------------------------------------------------------------
> > > > Vsevolod Sandomirskiy
> > > > Senior Software Engineer
> > > >
> > > > OC Systems
> > > >
> > > >
> > >
> > >
> > > --
> > > --------------------------------------------------------------------
> > > Vsevolod Sandomirskiy
> > > Senior Software Engineer
> > >
> > > OC Systems
> > >
> > >
> >
> >
> > --
> > --------------------------------------------------------------------
> > Vsevolod Sandomirskiy
> > Senior Software Engineer
> >
> > OC Systems
> >
> >
> >
> >
> >
>
>
> --
> --------------------------------------------------------------------
> Vsevolod Sandomirskiy
> Senior Software Engineer
>
> OC Systems
>
>


--
--------------------------------------------------------------------
Vsevolod Sandomirskiy
Senior Software Engineer

OC Systems



Back to the top