Community
Participate
Working Groups
Build ID: 20090619-0625 Steps To Reproduce: As I already mention on the message board CDO CVS Head due to the new type mapping mechanism works a bit other than CDO 2.0. But it's not only the type mapping, it's also the way the complete database is created by the DB store. In CDO 2.0 a database table was created on demand (if something was commited). With CDO Head all database tables are created the first time the database is accessed. The problem is that I mostly mix my models with classes that should be persisted to database and classes that are not intendet for persistence. Now with CDO Head many tables are created that are never used. Maybe we should add an annotation option to suppress a table creation for a specific class. More information:
Let's hear what Stefan says...
I don't like the bug name ([DB] Create tables lazily) because it implies a more specific solution. In fact, Kai gives us room for two options: 1. Create tables lazily. This is almost impossible for the already known reasons of DDL being non-transactional. It is also not very consistent, because if a rollback happens, the table is still there, even though empty - and we can not delete it because another transaction may already have inserted to it simultaneously. In my eyes, it is far more secure to associate the table creation task to the package registering (at server) task. (This is also how OR-mappers would work, I think). 2. Prevent table creation through an annotation. I like that idea. What about <eAnnotations source="http://www.eclipse.org/CDO/DBStore"> <details key="mapping" value="none"/> </eAnnotations> for not mapping the table and <eAnnotations source="http://www.eclipse.org/CDO/DBStore"> <details key="mapping" value="horizontal"/> </eAnnotations> for mapping the table using the horizontal strategy. (The latter is the default if no annotation is given). This would also leave the option to add other mapping strategies in the future.
(In reply to comment #2) > I don't like the bug name ([DB] Create tables lazily) because it implies a more > specific solution. Ok, then we need one more bugzillas :P > In fact, Kai gives us room for two options: > > 1. Create tables lazily. This is almost impossible for the already known > reasons of DDL being non-transactional. It is also not very consistent, because > if a rollback happens, the table is still there, even though empty - and we can > not delete it because another transaction may already have inserted to it > simultaneously. That's the same with the all-or-no-tables approach, only worse. In general I think it's better to have unused empty tables in rare cases (i.e. rollback) than in all cases. > 2. Prevent table creation through an annotation. I like that idea. I don't. It makes the whole EPackage unusable for other scenarios. > What about > > <eAnnotations source="http://www.eclipse.org/CDO/DBStore"> > <details key="mapping" value="none"/> > </eAnnotations> > > for not mapping the table and > > <eAnnotations source="http://www.eclipse.org/CDO/DBStore"> > <details key="mapping" value="horizontal"/> > </eAnnotations> > > for mapping the table using the horizontal strategy. That implies that the mapping strategy can be chosen per class and that's not true. We could consider that in a separate bugzilla but I foresee (solveable) challenges, e.g.: class C1 (vertical mapping) class C2 extends C1 (horizontal mapping) class C3 extends C2 (vertical mapping) Where is the C2 segment table of C3? >(The latter is the default > if no annotation is given). > > This would also leave the option to add other mapping strategies in the future.
Why not then an annotation for just turning off the mapping for a specific class (just yes or no instead of the mapping type)?
It makes the whole EPackage unusable for other scenarios.
I am sorry, but I can't follow entirely. What scenarios? Mapping scenarios?
An EPackage is something static and independent of any application logic. With this annotation you make this EPackage unusable for other applications. Right?
I had now some days to think about your "right?" ;-), but still don't get the point. When we annotate a class for example not to be created in the database by CDO, where do we change the EPackage (except of adding the annotation)? But even then, I use my model in an RCP application ... I am not interested if other applications could use my model. We even could point to such a problem (if there is really one) in the documentation. But I still don't get why we should not implement such an annotation and refuse that flexibility.
(In reply to comment #8) > I had now some days to think about your "right?" ;-), but still don't get the > point. > When we annotate a class for example not to be created in the database by CDO, > where do we change the EPackage (except of adding the annotation)? That's a change. And it belongs to the package. Nobody can ignore it. > But even then, I use my model in an RCP application ... I am not interested if > other applications could use my model. The question is: Do EPackages exclusively belong to a single application or are they meant to be reusable? In general, not only in your particular application! > We even could point to such a problem (if there is really one) in the > documentation. > But I still don't get why we should not implement such an annotation and refuse > that flexibility. Because the same can be achieved with lazy table creation, but more intelligently.
(In reply to comment #9) > (In reply to comment #8) > > I had now some days to think about your "right?" ;-), but still don't get the > > point. > > When we annotate a class for example not to be created in the database by CDO, > > where do we change the EPackage (except of adding the annotation)? > > That's a change. And it belongs to the package. Nobody can ignore it. But there is mostly a reason why a model designer says that this class shouldn't be persisted. It's like "transient" for an attribute (those are also static), but at the class level. > > But even then, I use my model in an RCP application ... I am not interested if > > other applications could use my model. > > The question is: Do EPackages exclusively belong to a single application or are > they meant to be reusable? In general, not only in your particular application! I would say, let the programmer/model designer decide. In my opinion it's more a restriction to don't allow it than allowing it and making the package not re-useable anymore. > > > We even could point to such a problem (if there is really one) in the > > documentation. > > But I still don't get why we should not implement such an annotation and refuse > > that flexibility. > > Because the same can be achieved with lazy table creation, but more > intelligently. Ok, thats a striking argument. But what would be a good way to do this? Simulate a table creation (maybe by creating it and deleting it again) and then later create it on lazily. Or at first only check the types and so on and later create the table lazily? Any other options?
Ok, your "transient feature" analogy convinced me. Plus the fact that lazy table creation would potentially slow down all commit operations because we need to discover unmapped classes *before* we iterate the new revisions. I propose: <eAnnotations source="http://www.eclipse.org/CDO/DBStore"> <details key="tableMapping" value="NONE"/> </eAnnotations>
Good ... I see what I can do in the upcoming days.
*** Bug 284481 has been marked as a duplicate of this bug. ***
Created attachment 144693 [details] Table Mapping Annotation Patch Here is the table mapping annotation implementation as promised (test included).
And before you have to tell me ;-) > 1) The number of lines that you changed (after copying from HSQLDB) is smaller > than 250. Confirmed. > > 2) You are the only author of these changed lines. Confirmed. > > 3) You apply the EPL to these changed lines. Confirmed.
Created attachment 144943 [details] patch-v2-ready-to-be-committed Reviewed and tested. Looks good. Thanks, Kai!
Committed to HEAD.
Available in 3.0 GA: http://download.eclipse.org/modeling/emf/cdo/updates/3.0-releases/
