Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

COSMOSPersistenceFrameworks

Revision as of 15:20, 24 April 2007 by Weitzelm.us.ibm.com (Talk | contribs) (Overview)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Overview

The COSMOS data collection framework is cognizant of the existence of existing data stores for monitored data. The key requirements for COSMOS are simplicity and a flexible object/relational mapping. When we started the initial work in COSMOS, for good or bad, we focused on execution and did not dig deeply into the pros or cons of using a particular persistence framework. As we move forward, the upcoming F2F in Toronto provides an opportunity to have this discussion and objectively evaluate our options.

This page is intended for us to have this discussion. It is a continuation of the e-mail thread started between Joel and Mark. The discussion on this page will be worked into the data collection architecture document being iterated on in CVS, and will then be made available on the COSMOS web site.

Here is a talk/discussion page on this.

COSMOS Persistence FW Core Requirements

There are only a handful of core requirements for the COSMOS persistence framework.

  • It must be simple for the user, be easily adoptable, and have low barriers of entry. We do not want to inadvertently create a barrier of adoption for COSMOS.
  • It must provide flexible handling of object <-> relational mapping.


Persistence Frameworks & Complexity

There are a number of persistence frameworks that satisfy the O/R requirement, but have varying degrees of complexity. The diagram below lists a number of the popular persistence frameworks along with their typical usage. It also places them along a complexity scale.


PersistenceFWComplexity.gif


Current work in COSMOS

TBD

Back to the top