Community
Participate
Working Groups
Build Identifier: 3.0.0 During commit of emf enum the attached exception occurred. Unfortunately I could not write a test case to reproduce the error. It has something to do with default values in EEnums. I was able to fix. The fix is attached. Reproducible: Sometimes
Created attachment 160743 [details] ClassCastException Access is an emf enum.
Martin, as the default value expert, can you please investigate this?
Created attachment 160745 [details] Proposed fix. Patch for project org.eclipse.emf.cdo.server.db
I just saw that there is a problem if no default value is set on the object using the enum.
@Eike All right. I'll have a look at it. Unfortunatelly I do not have the code in front of me right now but I remember having some trouble with Enums when creating the issSet tests. Could be related to this. .. @Erwin Thanks for the patch. I'll try to test it asap.
looks good to me. If Martin agrees, this can be applied.
Don't check-in the patch. There is still a problem: If there is no default set on the attribute using an enum a NPE is thrown (caused by getFeature().getDefaultValueLiteral() which is null). I don't know what value should be written to the db in this case.
After further investigation I found the following problem: The enum itself has always a default value. The InternalCDORevision holds a null value if an enum attribute was set to this default value. The TypeMapping class then searches for the default value which can be defined directly on the enum attribute (which can be null) but not on default defined on the EEnum. I assume that the method setDefaultValue(..) is only called if eIsSet returns true. I'll attach another patch which fetches the default from the enumeration itself if the attribute does not define a default value.
Created attachment 160769 [details] proposed fix. Takes also the default on the enum itself into account.
Erwin, I tried to reproduce the eror, nut unfortunatelly without success. I tried settable, not settable features with and without. Stored the enum attribute value and even the enums default. Nothing caused any problem in teh current implementation. Actually your second patch looks good, it does not seem to break anything, but Iwould feel better if were somehow able to reproduce this. Could you provide some more information about your model or even attach the concerning parts of it?
Created attachment 161085 [details] Proposed fix. Found another bug in my patch. The EEnumLiteral was fetched by name not literal.
I'll try to write an cdo test case. Up to now I've only written test cases using MemStores. How do I run a cdo test case based on a db store? Are there any existing test cases I could use as a template?
Hi Erwin, the test logic should usually be independent of the chosen backend (and other setup configuration details). With our cool test framework we run these test cases in several different scenarios.
I also detected the same issue with an emf generated model, cdo 3 (head) and a derby database. The patch handled the problem, thanks Erwin!
@Erwin Thanks for your efforts. You can have a look at the org.eclispe.emf.cdo.test.db plugin. See e.g. AllTestsDBH2.java. You can add the following method to the class to run only your test case. protected void initTestClasses(List<Class<? extends ConfigTest>> testClasses) { testClasses.add(MyTestCase.class); } If you run AllTestsDBH2.java only your test case will be executed on a H2 database. Ou rif you want you can write your own test config using AllTestsDBH2 as template. @Bjoern Thank for the info. That sounds promising. So I think we can apply the patch as soon as we have a test (making sure that any further development will not have a negative side effect on this repaired issue). Just a small question: What do you mean with "emf generated"? I hope you have converted to model to a CDO native one, because pure EMF is not yet supported in CDO.
@Martin Fluegge: Yes, sorry for not expressing myself clear here. It has of course been converted to a CDO native one.
Hi Erwin, Thanks for your patch. I changed it slightly. Please confirm the following: 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines.
Hi Eike, (In reply to comment #17) > Hi Erwin, > > Thanks for your patch. I changed it slightly. Please confirm the following: > > 1) The number of lines that you changed 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 @Martin: I have not had time to write a test case yet... ;-( Hope to do it next week.
Committed to HEAD
Available in 3.0 GA: http://download.eclipse.org/modeling/emf/cdo/updates/3.0-releases/
