Skip to main content
Jump to: navigation, search

Difference between revisions of "CDO"

Line 1: Line 1:
CDO is both a technology for ''distributed shared models'' and a fast, server-based ''O/R mapping'' solution. With CDO you can easily enhance your existing EMF models in such a way that they can be stored and subsequently maintained in a central model repository.
+
CDO is a 3-tiers solution for ''distributed shared models'' and a complete ''model repository''. With CDO you can easily enhance your existing EMF models in such a way that they can be stored and subsequently maintained in a central model repository. While object relational mapping against a JDBC data source on the server side is the shipped default CDO provides for ''pluggable storage adapters'' that allow you to develop and use different mappers (like Hibernate- or OODB-based). On the client side CDO provides a default integration with EMF, the Eclipse Modeling Framework, although other model integrations on top of the ''CDO protocol'' are imaginable as well.
 +
 
  
 
[[Image:CDOOverview.png]]
 
[[Image:CDOOverview.png]]
 +
 +
 +
==Features==
 +
 +
'''Model integration:'''
 +
* EMF integration on model level (as opposed to the edit level)
 +
* Support for generated models (just switch two .genmodel properties)
 +
* Support for dynamic models (just load .ecore file and commit to repository)
 +
* Support for legacy models (for compiled models without access to .genmodel)
 +
* Support for the Ecore meta meta model and descendants
 +
 +
'''CDO client:'''
 +
* Multiple sessions to multiple repositories on multiple servers
 +
* Multiple transactions per session
 +
* Multiple read-only views per session
 +
* Multiple audit views per session (an audit is a view that shows a consistent, historical version of a repository)
 +
* Multiple resources per view (a view is always associated with its own EMF ResourceSet)
 +
* Multiple root objects per resource
 +
* Object state shared among all views of a session
 +
* Object graph internally unconnected (unused parts of the graph can easily be reclaimed by the garbage collector)
 +
* Only new and modified objects committed in a transaction
 +
* Demand loading of objects (resources are populated as they are navigated)
 +
* Partial loading of collections (chunk size can be configured per session)
 +
* Adaptable pre-fetching of objects (different intelligent usage analyzers are available)
  
 
==Further Reading==
 
==Further Reading==
 
* [[CDO Client]]
 
* [[CDO Client]]
 
* [[CDO Server]]
 
* [[CDO Server]]

Revision as of 15:07, 18 October 2007

CDO is a 3-tiers solution for distributed shared models and a complete model repository. With CDO you can easily enhance your existing EMF models in such a way that they can be stored and subsequently maintained in a central model repository. While object relational mapping against a JDBC data source on the server side is the shipped default CDO provides for pluggable storage adapters that allow you to develop and use different mappers (like Hibernate- or OODB-based). On the client side CDO provides a default integration with EMF, the Eclipse Modeling Framework, although other model integrations on top of the CDO protocol are imaginable as well.


CDOOverview.png


Features

Model integration:

  • EMF integration on model level (as opposed to the edit level)
  • Support for generated models (just switch two .genmodel properties)
  • Support for dynamic models (just load .ecore file and commit to repository)
  • Support for legacy models (for compiled models without access to .genmodel)
  • Support for the Ecore meta meta model and descendants

CDO client:

  • Multiple sessions to multiple repositories on multiple servers
  • Multiple transactions per session
  • Multiple read-only views per session
  • Multiple audit views per session (an audit is a view that shows a consistent, historical version of a repository)
  • Multiple resources per view (a view is always associated with its own EMF ResourceSet)
  • Multiple root objects per resource
  • Object state shared among all views of a session
  • Object graph internally unconnected (unused parts of the graph can easily be reclaimed by the garbage collector)
  • Only new and modified objects committed in a transaction
  • Demand loading of objects (resources are populated as they are navigated)
  • Partial loading of collections (chunk size can be configured per session)
  • Adaptable pre-fetching of objects (different intelligent usage analyzers are available)

Further Reading

Back to the top