Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 256706

Summary:

Push CDO feature delegation concepts into core runtime

Product:

[Modeling] EMF

Reporter:

Cameron Bateman <cameron.bateman>

Component:

Core

Assignee:

Ed Merks <Ed.Merks>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

enhancement

Priority:

CC:

b.kolb, boris.gruschko, ekke, erche, i.am.joel, Kenn.Hussey, lu.xingxiao, rimvydas, saulius.tvarijonas, smcduff, stepper, tom.schindl, vroldanbet

Version:

2.5.0

Keywords:

plan

Target Milestone:

Helios

Flags:

Kenn.Hussey: helios+

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

256244

Attachments:

Description	Flags
v1 - initial design study	none

Description Cameron Bateman

2008-11-26 16:45:45 EST

This is an enhancement request opened at Ed's suggestion to track possible injection of CDO feature delegation concepts into the core.  The original discussion started at: 

http://www.eclipse.org/newsportal/article.php?id=37701&group=eclipse.tools.emf#37701

So far, we have the main the concept from http://www.eclipse.org/newsportal/article.php?id=37708&group=eclipse.tools.emf#37708 that:

"a store-based implementation [of EStore] that works effectively like a DynamicEobjectImpl until a store is associated so that folks can generate models that work without CDO but also can take advantage of all of CDO's facilities when used in that context."

which would allow that:

"Only once the object is added to a store-based resource (e.g, CDOResourceImpl) is a store associated and at that point, the "transient" state of the object is transfered to the store."

From my perspective, it would also be important to define my own "store-based resource" that does not rely CDO, so that I can define my storage re-association.

Comment 1 Eike Stepper

2009-12-24 05:41:56 EST

Created attachment 155013 [details]
v1 - initial design study

Comment 2 Ed Merks

2018-01-30 07:11:02 EST

This looks satel.