Eclipse Indigo - Strange JPA Problems in known-good code [message #717281] |
Fri, 19 August 2011 16:17  |
Eclipse User |
|
|
|
Hello, all!
I updated my Eclipse from Helios SR1 to Indigo a few days ago, and noticed that one of my primary projects now has a myriad of JPA problems which were obviously not showing up before. Just to be clear, the code in question is production code which builds, compiles, weaves statically (at build time, obviously) with EclipseLink 2.2.0, and runs perfectly in production.
Indigo is complaining about "the left parenthesis is missing from the IN expression", which is obviously incorrect (as per JPA 2.0 spec, the lack of such parenthesis denotes that the parameter is collection-typed), among a myriad of other apparently obvious syntax errors. The kind of syntax errors that clearly don't really exist but may be due to a "confused" parser.
These JPA problems appear to be related to changes in Indigo's parsing of JPA's @NamedQuery (and @NamedNativeQuery).
Here's a sample of the code being flagged (lines flagged have * on the left):
@NamedQuery(name = "fileItem.findLoggable", query = //
" select distinct i " + //
" from FileItem i " + //
* " where i.env = :env " + //
* " and i.state in :states " + //
* " and i.logged = false " + //
* " and i.env.enabled = true " + //
" and i.data.enabled = true " + //
" and i.owner.enabled = true " + //
" order by i.owner.id.name "),
There are other great many queries like this one in the file. Other JPA entity files have a similar set of @NamedQuery entries. We find this convenient since it groups the entity with all the queries that affect or retrieve instances.
The flagged errors are mostly "= cannot be resolved to a type" or "and cannot be resolved to a type" or the stranger still "is cannot be resolved to a type" (?!?! there's no word "is" in any of the queries!!)
Note the use of // and + to enable "pretty formatting" (albeit manual) for queries. Of importance is that I already attempted to eliminate the formatting (i.e. put it all in the same line, with single spaces, etc), to no avail.
Some details on the parameters for this particular: "env" is a JPA entity, "states" is a collection-typed set of enums (properly mapped to JPA - as I said, this code WORKS).
This is only one example, on one file. There are multiple such @NamedQuery entries on that file, and ALL of them produce problems. The fun fact is that if I remove all the @NamedQuery entries from one file, this will fix the problem but another file will then be flagged (i.e. not all files are flagged at once - seems to flag them one at a time)
Can you offer any guidance short of "turn off JPA validation"?
I can offer more specifics if needed - I just didn't want the post to be TOO long (probably too late for that ).
Thanks!
UPDATE: The following query also poses a different conundrum:
" delete " + //
" from FileItem i " + //
* " where exists ( " + //
" select c " + //
* " from Calendar c " + //
" where i.calendar = c " + //
" )" + //
" and i.env = :env")
The parser complains about "identification variable 's' is not defined in the FROM clause", and "identification variable 'i' is not defined in the FROM clause" (the 's' complaint is repeated on the 2nd line, so the 2nd line actually has 2 markers - one for 's' and one for 'i').
More weirdness...
[Updated on: Fri, 19 August 2011 16:30] by Moderator
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03254 seconds