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.
Difference between revisions of "CDO"
| Line 1: | Line 1: | ||
| − | CDO is | + | 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.
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)