Community
Participate
Working Groups
Tested against I-3.3.0-20110331154142 Create a JPA 2.0 project (Can be either Generic or EL) Connect to a Database (I used both oracle and DB2) Generate Entities from Tables (Selected Employee and Phone) Notice after the Entities are created you receive syntax errors on the version and type attributes. In the structure view the attribute shows as _version_ and in the editor it shows as @Column(name=""VERSION"") Syntax errors appear stating - Syntax error on token "VERSION", / expected I showed this to Nan and she was able to re-create the issue.
DTP has both Oracle and DB2 listing "VERSION" as a reserved word. I'm not sure that's correct... The recently-released database code now delimits reserved words when they are used as identifiers (which is what should be done). It appears the entity gen code is not appropriately escaping whatever it puts inside quotes.
At a glance, it would appear that it is reserved in DB2, but not in Oracle. This should be verified and a bug can be filed against DTP if necessary, but the general escaping issue needs to be addressed in Dali.
I could not find any mention of Oracle reserving the word VERSION; so submitted DTP bug 341936 for incorrect Oracle driver behavior. At least one version of DB2 have VERSION as a reserved word (http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0001095.htm).
Created attachment 193722 [details] proposed bug fix patch
I am also able to reproduce the issue. I was using Oracle XE 11g R2 (11.2 beta), the problem was with: @Column(name="STATE") private String _state_;
(In reply to comment #4) > Created attachment 193722 [details] > proposed bug fix patch This patch is a bit too far-reaching. :-) The DTP adapter code should return the identifier un-delimited. It's up to the client to figure out whether the returned string needs to be escaped. In particular, Java and XML will escape things differently, but both of them will end up calling AbstractDTPDriverAdapter.delimitName(...). So the escaping should be done in, possibly, GenericEntityGeneratorDatabaseAnnotationNameBuilder; since this is the crossover between database "identifier" and how that identifier gets put into Java source code. Also, instead of adding a method to StringTools; we already have a method that should do what's necessary: StringTools.convertToJavaStringLiteral(String). This method also handles any other embedded characters that need to escaped.
Created attachment 195164 [details] proposed bug fix patch
It would seem from the code that this patch wouldn't actually add the necessary delimiters that would need to be escaped unless I am not understanding what convertToJavaStringLiteral is supposed to do.
(In reply to comment #8) > It would seem from the code that this patch wouldn't actually add the necessary > delimiters that would need to be escaped unless I am not understanding what > convertToJavaStringLiteral is supposed to do. The column's "name" is already an "identifier"; i.e. it is already delimited if appropriate. (Calling it a "name" might not be entirely accurate, but it matches the annotation member's name....) Also, I'm guessing, from a cursory butcher, there are a number of other places that should be calling StringTools.convertToJavaStringLiteral(...): join.vm calls customizer.quote(...) a couple of times; and there could be problems with tables, join tables, and join columns.... Just making work for Les. :-)
Created attachment 195772 [details] proposed bug fix patch
Created attachment 196049 [details] patch with additional recommended changes Patch also includes fixes for @Table, @JoinTable, @JoinColumn annotations names to be properly escaped when name is reserved word. Also the patch removes fixes improper leading/trailing "_" for the generated attribute names.
Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This bug causes Dali to generate non-compiling classes in our Entity Gen functionality. This is a regression, and is likely to be seen often in real world cases. Is there a work-around? If so, why do you believe the work-around is insufficient? Workaround is to fix generated classes, which is possible, but inconvenient. It will also be broken again the next time generation is run. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? This fix has been tested over a series of days by Les and I. Give a brief technical overview. Who has reviewed this fix? The change ensure that all columns and tables are properly delimited when necessary by using the annotationBuilder, and that these delimited names are properly escaped when when being written to Java. What is the risk associated with this fix? Low-medium. Comprehensive testing is being used to minimize the risk of regression.
Approving so this can make it into Thursday's build. We can roll back if there are any objections from the PMC.
Committed to RC2.
Verified in Build I-3.3.0RC4-20110603221533 Verified no syntax errors appear when you generate entites from tables. See the link to view test steps for verification. http://wiki.eclipse.org/Dali_3.0_RC2
