Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] 9L JPQL long literal incorrectly parsed in 2.4, 0, 2.41, but worked in 2.3.3 and earlier

I opened bug 407095.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=407095

Unfortunately, the workaround doesn't help me as I was upgrading to
2.4 in order to get "Order By foo NULLS FIRST" support which seems to
only exist in the new parser.

We'll rework our code to stop using "L"



On Thu, May 2, 2013 at 1:22 PM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:
> You should use this as a workaround.  Please file a bug for the issue.
>
> In 2.4.2 we changed to a new JPQL parser.  This workaround enables the old
> one.
>
> -Tom
>
>
> On 02/05/2013 1:10 PM, Mike Kienenberger wrote:
>>
>> Yes, it appears to work.
>>
>> Adding
>>
>>              <property name="eclipselink.jpql.parser"
>> value="org.eclipse.persistence.queries.ANTLRQueryBuilder"/>
>>
>> to my persistence.xml file results in:
>>
>> EJBQueryImpl(ReadAllQuery(referenceClass=JpaAction sql="SELECT id,
>> inactivation_time, is_active, name, permission_category, system_id
>> FROM sec_action WHERE (system_id = ?)"))
>>
>> Should I use this as a work-around, or is this just a diagnostic step
>> you needed from me?
>>
>>
>> On Thu, May 2, 2013 at 1:04 PM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:
>>>
>>> Does it work if you add the following persistence unit property to your
>>> persistence.xml?
>>>
>>> eclipselink.jpql.parser=org.eclipse.persistence.queries.ANTLRQueryBuilder
>>>
>>>
>>> On 02/05/2013 12:34 PM, Mike Kienenberger wrote:
>>>>
>>>>
>>>> Starting in Ecllipselink 2.4.0, A JPQL long literal incorrectly is
>>>> parsed.
>>>> The same issue is true for 2.4.1, but worked from Eclipselink 1.2 all
>>>> the way through 2.3.3.
>>>>
>>>> simple example:
>>>> ======
>>>>     public static void main(String[] args) {
>>>>           EntityManagerFactory emf =...;
>>>>           EntityManager em = emf.createEntityManager();
>>>>
>>>>           String jpqlString = "select action from JpaAction action where
>>>> action.systemId = 9L";
>>>>           Query q = em.createQuery(jpqlString);
>>>>           System.out.println(q);
>>>>       }
>>>> ======
>>>>
>>>> Results in
>>>>
>>>> EJBQueryImpl(ReadAllQuery(referenceClass=JpaAction sql="SELECT
>>>> DISTINCT id, inactivation_time, is_active, name, permission_category,
>>>> system_id FROM sec_action WHERE (system_id IS NULL)"))
>>>>
>>>>
>>>> Changing it to "9" from "9L" results in
>>>>
>>>> EJBQueryImpl(ReadAllQuery(referenceClass=JpaAction sql="SELECT id,
>>>> inactivation_time, is_active, name, permission_category, system_id
>>>> FROM sec_action WHERE (system_id = ?)"))
>>>>
>>>>
>>>> Has the JPQL specification changed, or is this a bug introduced in the
>>>> 2.4 branch?
>>>>
>>>>
>>>>
>>>> http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying/JPQL#Literals
>>>> indicates that this is still valid grammar.
>>>>
>>>> It's unclear to me after reading the specification whether 9L is a
>>>> valid format since only a Java integer exact numeric literal is
>>>> mentioned:
>>>>
>>>> =====================================
>>>> 4.6.1
>>>> Literals
>>>> A string literal is enclosed in single quotes—for example: ‘literal’.
>>>> A string literal that includes a single
>>>> quote is represented by two single quotes—for example:
>>>> ‘literal’’s’. String literals in queries, like Java
>>>> String
>>>> literals, use unicode character encoding. The use of Java escape
>>>> notation is not supported in
>>>> query string literals.
>>>> Exact numeric literals support the use of Java integer literal syntax
>>>> as well as SQL exact numeric literal
>>>> syntax.
>>>> Approximate literals support the use Java floating point literal
>>>> syntax as well as SQL approximate
>>>> numeric literal syntax.
>>>> Appropriate suffixes can be used to indicate the specific type of a
>>>> numeric literal in accordance with the
>>>> Java Language Specification. Support for the use of hexadecimal and
>>>> octal numeric literals is not
>>>> required by this specification.
>>>> =====================================
>>>>
>>>> Thanks,
>>>>
>>>> -Mike
>>>> _______________________________________________
>>>> eclipselink-users mailing list
>>>> eclipselink-users@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>>>
>>> _______________________________________________
>>> eclipselink-users mailing list
>>> eclipselink-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users


Back to the top