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

Bug 268663

Summary: Rework CDO type system
Product: [Modeling] EMF Reporter: Eike Stepper <stepper>
Component: cdo.coreAssignee: Project Inbox <emf.cdo-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: chewbizz, saulius.tvarijonas, smcduff
Version: 4.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 265435    
Bug Blocks: 254698, 269789    

Description Eike Stepper CLA 2009-03-15 07:05:45 EDT 
Now, that Ecore is available on the server, the internal type system should be redesigned from ground up. We should have all type-related operations (like serialization, deserialization, value cloning, ID adjustment, etc...) encapsulated in the type handler implementations. Custom type handlers should be contributed via extpoint and associated with features via EAnnotations. Type handlers should be automatically derived from a features if no annotation is present.
Comment 1 Simon Mc Duff CLA 2009-03-15 09:39:21 EDT 
With your latest changed in CDOModelUtil ... (moving EEnum out of getCOreType) introduce a mistake. (even if all testcases passed).

When convertToCDO is called the following code is called:
else if (feature.getEType() instanceof EDataType)
      {
        EDataType eType = (EDataType)feature.getEType();
        CDOType type = CDOModelUtil.getCoreType(eType);
        if (type == null)
        {
          value = EcoreUtil.convertToString(eType, value);
        }
      }
EEnum is a EDataType...but it is not associated with a coretype. Should we call CDOModelUtil.getType instead of getCoreType ?

Since CDOTypeImpl of EENUm is dealing with String(before it was Integer and it should be integer) we are only lucky that it is working. (One side we used... EcoreUtil.convertToString the other side we take CDOType.

Maybe you wanted to refactor this part of this bug # 268663.
Comment 2 Simon Mc Duff CLA 2009-03-28 15:10:41 EDT 
I've started to develop this feature ... but at the end EEnum is still a problem.
Here my problem:
With this refactoring I wanted to remove the conversion from the CDOStore.convertToEMF CDOStore.convertToCDO. The problem with EEnum is that if I do not transfer it, I can write it (transfer in a integer)  but cannot read it since only with the number... I cannot do much. ? Should we leave it as a number ? ... in this case I will still need the convertToEMF for EENum.

Simon
Comment 3 Simon Mc Duff CLA 2009-03-29 09:07:36 EDT 
CDOType now have a convertToEMF and convertToCDO. THe only one using it so far is EENum.

The CDORevision will contains only the integer of the value EEnum. It will NOT contains the Enum value. If the back-end needs that value... it will need to convert himself or to use EObject. (Now that it is possible). At the moment, DBStore used EENumLiteral... it shouldn't. Should I update the code as well ? Does it make sense ?

Also, since project dependency is yet not completed,  conversion from EObject to CDOID will still happen in CDOStore. Common package doesn't know anything about InternalCDOView. :-(
Comment 4 Simon Mc Duff CLA 2009-03-29 12:44:02 EDT 
Another question i have :

Let's say the user defined it's own CDOValueHandler. How the back-end will store it ? I mean..must it to be a String... or a model or something else ?
Comment 5 Eike Stepper CLA 2009-11-01 05:57:54 EST 
Rebasing all unresolved enhancement requests to 3.0
Comment 6 Eike Stepper CLA 2010-06-29 04:49:51 EDT 
Rebasing all outstanding enhancements requests to version 4.0
Comment 7 Eike Stepper CLA 2011-06-23 03:56:26 EDT 
Moving all open enhancement requests to 4.1
Comment 8 Eike Stepper CLA 2011-07-16 10:59:27 EDT 
No interest for years. WONTFIX.
Comment 9 Eike Stepper CLA 2012-09-21 07:15:55 EDT 
Closing.