Case sensitivity in JPQL queries

[lukasj]

In JPA 2.0, JPQL is case insensitive. This means that contrary to Java code, an identifier can not be same name as an entity with the first letter in lower case.

For instance in the following query an underscore has to be added to make the name legal:

SELECT
    _user
FROM
    User _user

Other typical workarounds for this are abbreviating the identifier to e.g. "u", "usr" etc. Such names are rarely a best practice and actually against common advice for good naming given by books like Clean Code, etc.

I would like to request support for case sensitivity in some way, or alternatively to lift the requirement that identifiers may not have the same name as Entity classes. This last approach is taken by some persistence providers, e.g. Hibernate, which silently accepts identifiers having the same name as Entities.

One possible solution would be to use a setting, either per query or globally for the entire persistence unit. E.g.

<named-query name="User.getAll" caseSensitive="true">
    <query>
        SELECT
            user
        FROM
            User user
    </query>
</named-query>

[lukasj]

@glassfishrobot Commented
Reported by @arjantijms

[lukasj]

@glassfishrobot Commented
c.beikov said:
Would it break backwards compatibility? I don't think so.
IMO this is an important addition when there is no reason for not including it. Many developers just use "propritary features" of their persistence providers and don't even know for sure that it isn't standard. I used hibernate ever since and I didn't know JPQL is case insensitive. So if I really want to deploy my applications to servers that do not have hibernate on them and the JPA implementation of the target system is not case sensitive, I would have to rewrite 300+ queries to get it working

Please consider the addition or give reasons for not doing it!

[lukasj]

@glassfishrobot Commented
pbenedict said:
Interesting addition. Adding caseSensitive to both the descriptor and @NamedQuery seems sensible, but most queries that I've seen (SQL and JPQL) have standardized on the one letter alias convention. I probably did hit this problem once but it's just too easy to use another alias.

[lukasj]

@glassfishrobot Commented
This issue was imported from java.net JIRA JPA_SPEC-30

[lukasj]

• Issue Imported From: https://github.com/javaee/jpa-spec/issues/30
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @ldemichiel

[gavinking]

In JPA 2.0, JPQL is case insensitive. This means that contrary to Java code, an identifier can not be same name as an entity with the first letter in lower case.

To be clear: keywords and identification variables are case-insensitive.

The spec is actually silent on the question of whether entity names and field references in path expressions are case-sensitive (oops!), but it's strongly implied, and intended, that they are case-sensitive.

I'm very surprised to hear that a entity names like User can be confused with an identification variable like user, since there occur in syntactically distinguishable locations! Hibernate has always accepted from User user and I would have thought that other implementations also support this.

That said, I think it was a mistake to say that identification variables are case-insensitive, and I wouldn't mind fixing that. But I can't think of a good and elegant way to fix it that doesn't imply breaking backward compatibility.

So how about we just flatly state in the spec that from User user is acceptable, and that entity names live in a different namespace to identification variables? That's like a one-line fix. WDYT?

[gavinking]

See proposed fix #449.

[gavinking]

I'm very surprised to hear that entity names like User can be confused with an identification variable like user, since there occur in syntactically distinguishable locations!

Well, that's perhaps overstating the case slightly. We also need to consider disambiguating entity_type_literal from identification variables in the expression grammar.

Now, in the BNF grammar defined by the specification, these actually are distinguished syntactically, since an entity_type_expression cannot be an identification_variable. But the spec grammar is a bit "funny" in this respect, and mixes up parsing and typing, which most implementations surely do in separate phases.

Nevertheless, even if an expression like:

type(user) = User

is ambiguous to the parser, it can easily be disambiguated during semantic analysis. And that's the only place an entity_type_literal can occur.

It's certainly quite clear from the BNF that User in this code example cannot possibly be an identification variable.