0

According to JPA 2.0 spec, when defining delimited identifiers (useful for those that match reserved words) escaped double quotes \" must be used. For instance, an entity in a table named USER should be annotated @Table(name = "\"USER\"").

In 1.0 this was not specified and a workaround would consist in using whichever database syntax was. For instance, using backticks ` in MySQL, @Table(name = "`USER`"), or square brackets [] in SQL Server, @Table(name = "[USER]").

When validating classes, Eclipse seems not to be respecting the quoting in JPA 2.0 and resolves the identifier plainly with the double quotes. Although I'm using EclipseLink 2.5.2 in Eclipse Luna, that should be up to date, it is unable to resolve the identifiers quoted as specified, and thus marks it as an error.

From what I've investigated, it seems to be some problem between Dali (the persistence plugin) and the DTP (that provides the access to the databases). When using non delimited identifiers it resolves fine, but those are required to make it work with JPA Tools and deployed, this just happens in the Eclipse IDE.

Is there a workaround to make it resolve those elements properly?

Using double quotes acording to JPA 2.0

Using MySQL notation

Information of the marker

JPA configuration in Eclipse

Yago Méndez Vidal
  • 884
  • 8
  • 23
  • Try using `\\\"User\\\"`. – Tassos Bassoukos Sep 23 '14 at 06:31
  • That way it doesn't resolve it either. – Yago Méndez Vidal Sep 23 '14 at 06:36
  • Then you need to copy the error marker here, as there's not much to go on... – Tassos Bassoukos Sep 23 '14 at 06:37
  • The marker just says "Table ""USER"" cannot be resolved". I'm adding it. – Yago Méndez Vidal Sep 23 '14 at 06:44
  • this probably happens because your DB already has a 'user' table (PostgreSQL comes to mind...). – Tassos Bassoukos Sep 23 '14 at 08:01
  • @Yago Méndez Vidal: How does your `Properties > JPA` configuration dialog in Eclipse look like? Paste a screenshot if possible. – wypieprz Sep 25 '14 at 19:17
  • Here it is, just added it. – Yago Méndez Vidal Sep 26 '14 at 07:02
  • The problem relies in that Eclipse tries to resolve "USER" for MySQL instead of converting it to \`USER\`, according to JPA 2.0 specification that makes it platform independent. At this point I'm considering using backticks and postprocessing the sources before building for changing them into \" but that would "corrupt" the code. – Yago Méndez Vidal Sep 27 '14 at 08:16
  • 1
    Sorry I missed your question (5 months ago!). Dali recognizes the database platform-specific delimiters. In the case of MySQL, that would be a backtick (`\``); unless you have configured your server to use `ANSI_QUOTES` (which Dali also checks for). So: you could use backtick delimiters in your annotations (e.g. `"\`USER\`"`) or configure your server to use `ANSI_QUOTES` or try specifying the `` in your `persistence.xml`. – Brian Vosburgh Feb 25 '15 at 21:40
  • @BrianVosburgh Any response is welcome, any time. Specific delimiters do work fine, but my purpose was using the JPA 2.0 reccomendation for using \" (double quotes, but escaped) because this project is intended to be deployed in 3 different environments (with at least MySQL and Informix different dataabses) and probably more, and wanted to take the most standard approach. Nevertheless, using and removing all quotation in annotations did the trick. My question is: Shouldn't Dali resolve \" as the corresponding specific database quotation when using JPA 2.0 instead of "? – Yago Méndez Vidal Mar 03 '15 at 09:40
  • 1
    Yes, Dali _should_ resolve identifiers surrounded by the spec-recommended delimiters. But Dali has resolved identifiers with database-specific delimiters since JPA 1.0 - as the spec did not address case sensitivity at all in that version. Since there has been very little demand for the careful handling of case sensitivity and the implementation is pretty complicated (across all the database platforms), the developers have not enhanced that behavior. In particular, the `` element has solved most problems. Anyway: it's fun that someone, somewhere cares about this :-) – Brian Vosburgh Mar 04 '15 at 03:10

0 Answers0