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

Bug 284481

Summary:	[DB] Types are mapped before anything is stored to the database
Product:	[Modeling] EMF	Reporter:	Kai Schlamp <schlamp>
Component:	cdo.db	Assignee:	Project Inbox <emf.cdo-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	stepper
Version:	3.0
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Kai Schlamp

2009-07-23 14:43:01 EDT

Build ID: 20090619-0625

Steps To Reproduce:
Kai:
My model has indeed a custom field (EJavaObject), but I never commit any of those objects with this feature structure into the database.
CDO 2.0 could live with that and was never interested in that never persisted object. In contrast CDO CVS Head now is interested in those objects when setting up the database and throws the below exception.
In my opinion we should make CDO Head behave as CDO 2.0. Only do mappings when needed.
Transient indeed works (I already solved it that way). But in my opinion it's more a conceptual question of how CDO works. Why does CDO bother with type mappings when nothing is intended to be committed. But I am still not sure for myself ... is it intended or even a feature?!
As I said, it behave differently when using CDO 2.0 that's why it attracted my attention. 


Eike:
I'd say it's intended. From a conceptual point of view it sounds odd to
allow things that are known to violate assumptions and hope that it will
not occur. Technically it's next to impossible to lazily create missing
mappings. SQL does not seem to define a standard way how to execute DDL.
Some vendors do it in the normal transaction, some do it outside, others
implicitely commit the ongoing transaction before and after DDL.

More information:

Comment 1 Kai Schlamp

2009-07-23 14:50:06 EDT

I mostly have a mixed model. The model contains stuff that is persisted by CDO and stuff that is not persisted by CDO. I don't like to divide it into two models as from a design view it is really one model. With CDO Head I have to use "transient" for some of those never to the database persisted objects. At the moment I don't have any problem with that. But what if I want to serialize one of those objects with the help of EMF. There are maybe EMF types that are serializeable, but are not implemented as db types within CDO. CDO won't allow me to use transient then, although I just want to serialize it with EMF. Just a thought and a theoretical case.
As I said, I don't have a problem with it. Just to the contrary, I like the thought that everything is checked in advance.
Just want to be sure here that everything is intended as it is.

Comment 2 Eike Stepper

2009-08-03 12:57:19 EDT

How does this differ from the enhancement request in bug 284680, other than here you are implying a defect?

*** This bug has been marked as a duplicate of bug 284680 ***

Comment 3 Kai Schlamp

2009-08-03 13:30:50 EDT

This must have been created by one of my other multiple personalities ;-) You are right ... same issue, just from a different view.

Comment 4 Eike Stepper

2009-08-03 13:34:55 EDT

Kai[], No problem :P

Comment 5 Eike Stepper

2010-06-29 04:44:25 EDT

Closing