Re: [eclipselink-users] NumberFormat exception when searching for numeri

[mgsoft <mgsoft@xxxxxx>]

Hello Christopher,

here my setup:

Glassfish v3
MySQL 5.1
EclipseLink 2.0

Sorry, but I disagree. The statement "EclipseLink just passes your queries
through to the database, so it is the database that doesn' support it." is
not true (at least the part of the statement concerning the database
support)! The translated native query (select * from material_tab where id
like '12%' )works - at least for the MySQL database that we use in our
project! 

Anyway - I will try to update to EclipseLink 2.2.


christopher delahunt wrote:
> 
> EclipseLink just passes your queries through to the database, so it is 
> the database that doesn't support it.  You cannot search numeric fields 
> like you do strings, which is why Michael suggested you store the data 
> in the database as a string type instead. 
> Numeric operations such as greaterthan, lessthan etc work on numerics.  
> Or, you can try converting the field to a string using the TO_STRING 
> function if your database supports it.  Ie:
>   "select a.id from Material a where FUNC( 'TO_STRING", a.id ) like '12%'"
> 
> Best Regards,
> Chris
> 
> 
> On 04/04/2011 8:58 AM, mgsoft wrote:
>> Does that mean that EclipseLink doesn't support that use-case at all?
>>
>> The problem is that the project I am working on is quite big. We have
>> some
>> hundreds of entity beans and I cannot change the domain model. Moreover
>> your
>> workaround would result in enormous efforts to change our existing
>> database.
>> No way!
>>
>>
>>
>> mobrien wrote:
>>   
>>> mgsoft,
>>>      good use case.  One alternate option could be to store the field as 
>>> a String/VARCHAR on the database and use an EclipseLink native 
>>> @TypeConverter - so we could use it as numeric field like a Long, 
>>> Integer or BigInteger when in JPA.
>>>      Here is a example of this case where we needed to get around the 
>>> 10^19 or 2^63 size limitation of the NUMERIC field imposed on unbounded 
>>> BigInteger objects by all databases by using a TypeConverter.
>>>
>>> http://wiki.eclipse.org/EclipseLink/Examples/Distributed#DI_5:_Limitations_of_BigInteger_translation_to_BIGINT_Database_DataType
>>>
>>> @Entity
>>> @TypeConverters({@TypeConverter(name="BigIntegerToString",dataType=String.class,objectType=BigInteger.class)})
>>> public  class  Parametersimplements  Serializable  {
>>>      @Column(name="maxValue", nullable=false, length=512)
>>>      @Convert("BigIntegerToString")
>>>      private  BigInteger  maxValue;
>>>
>>>
>>>      One of the clients of this distributed app also uses a brute force 
>>> ajax client.
>>>      thank you
>>>      /michael
>>>
>>>
>>> On 2011-04-02 04:19, mgsoft wrote:
>>>     
>>>> I have got a webapplication that contains an AJAX-driven autocomplete
>>>> field
>>>> that is mapped to a numeric field of type long.
>>>> As soon as the user enters at least two characters an AJAX-request is
>>>> sent
>>>> to the server that in turn should query the database in order to fetch
>>>> a
>>>> list of possible items.
>>>>
>>>> The query is very simple:
>>>>
>>>> select a.id from Material a where a.id like '12%'
>>>>
>>>> But that query doesn't work! I get an EclipseLink conversion exception
>>>> that
>>>> is
>>>>
>>>> Caused by: java.lang.NumberFormatException: For input string: "12%"
>>>>
>>>> Please tell me how to use wildcards when searching for numeric fields!
>>>> Thank
>>>> you very much.
>>>>
>>>>
>>>>       
>>> _______________________________________________
>>> 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
> 
> 

-- 
View this message in context: http://old.nabble.com/NumberFormat-exception-when-searching-for-numeric-fields-tp31301734p31314967.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.