I am getting an exception when I submitted order in ecommerce

[Akash Jain-4]

Hello all,

I am getting an exception when I submitted order in ecommerce.

(1) First I add a product to cart.(add to cart)
(2) Then click on checkout.(One Page Checkout)
I am getting an exception like

 DATABASE TYPE error IN GenericEntity.set In entity field [OrderPaymentPreference.maxAmount] set the value passed in [java.math.BigDecimal] is not compatible with the Java type of the field [Double]

after submitting order.(Submit Order)

( I am working on  726678 Revision)

Thanks in advance

Regards
Akash Jain
Hotwaxmedia Pvt. Ltd.

[Jacques Le Roux]

I got the same type of problem in OrderServices.createOrder method when calling service countProductQuantityOrdered
I changed the line
<set field="productCalculatedInfo.totalQuantityOrdered" value="${productCalculatedInfo.totalQuantityOrdered +
parameters.quantity}"/>
to
<set field="productCalculatedInfo.totalQuantityOrdered" value="${productCalculatedInfo.totalQuantityOrdered + parameters.quantity}"
type="Double"/>

I guess it's related to recent UEL change and, as David said, we will cross a lot of same issues...

Jacques

From: "Akash Jain" <[hidden email]>

> Hello all,
>
> I am getting an exception when I submitted order in ecommerce.
>
> (1) First I add a product to cart.(add to cart)
> (2) Then click on checkout.(One Page Checkout)
> I am getting an exception like
>
> DATABASE TYPE error IN GenericEntity.set In entity field [OrderPaymentPreference.maxAmount] set the value passed in
> [java.math.BigDecimal] is not compatible with the Java type of the field [Double]
>
> after submitting order.(Submit Order)
>
> ( I am working on  726678 Revision)
>
> Thanks in advance
>
> Regards
> Akash Jain
> Hotwaxmedia Pvt. Ltd.
>

[David E Jones-3]

That's a funny one, since the syntax used was not supported before UEL  
was introduced, and I mean the original line without your change  
Jacques. In other words this attribute would not work without UEL:

value="${productCalculatedInfo.totalQuantityOrdered +  
parameters.quantity}"

I guess somehow the type casting was missed so whatever UEL defaults  
to was used. If that was BigDecimal, then we should LEAVE it as  
BigDecimal and not cast it to a Double. Yes, for now there will be  
warnings (which is all that the reported message was), but there is a  
separate branch that mostly Scott Gray is working on to get everything  
moved over from Double to BigDecimal, and until then the warnings are  
a good thing and we shouldn't try to fix each one.

For everyone, when you see that warning message just consider a  
reminder that there is an effort going on to move from Double to  
BigDecimal and without it there are issues in OFBiz, so your help on  
the effort will help you too.

-David


On Dec 16, 2008, at 11:21 AM, Jacques Le Roux wrote:

> I got the same type of problem in OrderServices.createOrder method  
> when calling service countProductQuantityOrdered
> I changed the line
> <set field="productCalculatedInfo.totalQuantityOrdered" value="$
> {productCalculatedInfo.totalQuantityOrdered + parameters.quantity}"/>
> to
> <set field="productCalculatedInfo.totalQuantityOrdered" value="$
> {productCalculatedInfo.totalQuantityOrdered + parameters.quantity}"
> type="Double"/>
>
> I guess it's related to recent UEL change and, as David said, we  
> will cross a lot of same issues...
>
> Jacques
>
> From: "Akash Jain" <[hidden email]>
>> Hello all,
>>
>> I am getting an exception when I submitted order in ecommerce.
>>
>> (1) First I add a product to cart.(add to cart)
>> (2) Then click on checkout.(One Page Checkout)
>> I am getting an exception like
>>
>> DATABASE TYPE error IN GenericEntity.set In entity field  
>> [OrderPaymentPreference.maxAmount] set the value passed in
>> [java.math.BigDecimal] is not compatible with the Java type of the  
>> field [Double]
>>
>> after submitting order.(Submit Order)
>>
>> ( I am working on  726678 Revision)
>>
>> Thanks in advance
>>
>> Regards
>> Akash Jain
>> Hotwaxmedia Pvt. Ltd.
>>
>

[Jacques Le Roux]

On Postgres it's not only a warning but really an error. The transaction is rolled back and you can't create an order from eCommerce
without that change.
I used Double since that's what was used 3 lines above for the same variable.
I just tried with BigDecimal, it works too. But I'm not sure it makes more sense to use BigDecimal as it's about a quantity
(totalQuantityOrdered).
I never saw a rational quantity used but I guess Long would not fit well here in case somebody would have the need for rational
quantities.
Do you want I put BigDecimal instead ?

Jacques

From: "David E Jones" <[hidden email]>

>
> That's a funny one, since the syntax used was not supported before UEL  was introduced, and I mean the original line without your
> change  Jacques. In other words this attribute would not work without UEL:
>
> value="${productCalculatedInfo.totalQuantityOrdered +  parameters.quantity}"
>
> I guess somehow the type casting was missed so whatever UEL defaults  to was used. If that was BigDecimal, then we should LEAVE it
> as  BigDecimal and not cast it to a Double. Yes, for now there will be  warnings (which is all that the reported message was), but
> there is a  separate branch that mostly Scott Gray is working on to get everything  moved over from Double to BigDecimal, and
> until then the warnings are  a good thing and we shouldn't try to fix each one.
>
> For everyone, when you see that warning message just consider a  reminder that there is an effort going on to move from Double to
> BigDecimal and without it there are issues in OFBiz, so your help on  the effort will help you too.
>
> -David
>
>
> On Dec 16, 2008, at 11:21 AM, Jacques Le Roux wrote:
>
>> I got the same type of problem in OrderServices.createOrder method  when calling service countProductQuantityOrdered
>> I changed the line
>> <set field="productCalculatedInfo.totalQuantityOrdered" value="$ {productCalculatedInfo.totalQuantityOrdered +
>> parameters.quantity}"/>
>> to
>> <set field="productCalculatedInfo.totalQuantityOrdered" value="$ {productCalculatedInfo.totalQuantityOrdered +
>> parameters.quantity}"
>> type="Double"/>
>>
>> I guess it's related to recent UEL change and, as David said, we  will cross a lot of same issues...
>>
>> Jacques
>>
>> From: "Akash Jain" <[hidden email]>
>>> Hello all,
>>>
>>> I am getting an exception when I submitted order in ecommerce.
>>>
>>> (1) First I add a product to cart.(add to cart)
>>> (2) Then click on checkout.(One Page Checkout)
>>> I am getting an exception like
>>>
>>> DATABASE TYPE error IN GenericEntity.set In entity field  [OrderPaymentPreference.maxAmount] set the value passed in
>>> [java.math.BigDecimal] is not compatible with the Java type of the  field [Double]
>>>
>>> after submitting order.(Submit Order)
>>>
>>> ( I am working on  726678 Revision)
>>>
>>> Thanks in advance
>>>
>>> Regards
>>> Akash Jain
>>> Hotwaxmedia Pvt. Ltd.
>>>
>>
>

[David E Jones-3]

If that is the case then there must have been a different error  
message than the one quoted in the first message by Akash:

"DATABASE TYPE error IN GenericEntity.set In entity field  
[OrderPaymentPreference.maxAmount] set the value passed in  
[java.math.BigDecimal] is not compatible with the Java type of the  
field [Double]"

That error comes from GenericEntity.java and there is no exception  
thrown or anything that would cause a rollback.

What was the error that caused the rollback? I'm thinking that it  
would be best to use a type="BigDecimal", but I don't know because I  
don't know what the problem was you were trying to fix...

-David


On Dec 17, 2008, at 7:34 AM, Jacques Le Roux wrote:

> On Postgres it's not only a warning but really an error. The  
> transaction is rolled back and you can't create an order from  
> eCommerce without that change.
> I used Double since that's what was used 3 lines above for the same  
> variable.
> I just tried with BigDecimal, it works too. But I'm not sure it  
> makes more sense to use BigDecimal as it's about a quantity  
> (totalQuantityOrdered).
> I never saw a rational quantity used but I guess Long would not fit  
> well here in case somebody would have the need for rational  
> quantities.
> Do you want I put BigDecimal instead ?
>
> Jacques
>
> From: "David E Jones" <[hidden email]>
>>
>> That's a funny one, since the syntax used was not supported before  
>> UEL  was introduced, and I mean the original line without your  
>> change  Jacques. In other words this attribute would not work  
>> without UEL:
>>
>> value="${productCalculatedInfo.totalQuantityOrdered +  
>> parameters.quantity}"
>>
>> I guess somehow the type casting was missed so whatever UEL  
>> defaults  to was used. If that was BigDecimal, then we should LEAVE  
>> it as  BigDecimal and not cast it to a Double. Yes, for now there  
>> will be  warnings (which is all that the reported message was), but  
>> there is a  separate branch that mostly Scott Gray is working on to  
>> get everything  moved over from Double to BigDecimal, and until  
>> then the warnings are  a good thing and we shouldn't try to fix  
>> each one.
>>
>> For everyone, when you see that warning message just consider a  
>> reminder that there is an effort going on to move from Double to  
>> BigDecimal and without it there are issues in OFBiz, so your help  
>> on  the effort will help you too.
>>
>> -David
>>
>>
>> On Dec 16, 2008, at 11:21 AM, Jacques Le Roux wrote:
>>
>>> I got the same type of problem in OrderServices.createOrder  
>>> method  when calling service countProductQuantityOrdered
>>> I changed the line
>>> <set field="productCalculatedInfo.totalQuantityOrdered" value="$  
>>> {productCalculatedInfo.totalQuantityOrdered +  
>>> parameters.quantity}"/>
>>> to
>>> <set field="productCalculatedInfo.totalQuantityOrdered" value="$  
>>> {productCalculatedInfo.totalQuantityOrdered + parameters.quantity}"
>>> type="Double"/>
>>>
>>> I guess it's related to recent UEL change and, as David said, we  
>>> will cross a lot of same issues...
>>>
>>> Jacques
>>>
>>> From: "Akash Jain" <[hidden email]>
>>>> Hello all,
>>>>
>>>> I am getting an exception when I submitted order in ecommerce.
>>>>
>>>> (1) First I add a product to cart.(add to cart)
>>>> (2) Then click on checkout.(One Page Checkout)
>>>> I am getting an exception like
>>>>
>>>> DATABASE TYPE error IN GenericEntity.set In entity field  
>>>> [OrderPaymentPreference.maxAmount] set the value passed in
>>>> [java.math.BigDecimal] is not compatible with the Java type of  
>>>> the  field [Double]
>>>>
>>>> after submitting order.(Submit Order)
>>>>
>>>> ( I am working on  726678 Revision)
>>>>
>>>> Thanks in advance
>>>>
>>>> Regards
>>>> Akash Jain
>>>> Hotwaxmedia Pvt. Ltd.
>>>>
>>>
>

[Jacques Le Roux]

Hi DAvid,

Here is the error

2008-12-18 05:20:12,390 (http-0.0.0.0-18443-1) [            UtilXml.java:241:INFO ] XML Read 0.047s:
file:/D:/workspace/ofbizRun/applications/product/script/org/ofbiz/product/product/ProductServices.xml
2008-12-18 05:20:12,484 (http-0.0.0.0-18443-1) [   GenericDelegator.java:1280:ERROR]
---- exception report ----------------------------------------------------------
Failure in store operation for entity [ProductCalculatedInfo]: org.ofbiz.entity.GenericEntityException: Error while updating:
[GenericEntity:ProductCalculatedInfo][averageCustomerRating,null()][createdStamp,2
008-12-05 19:30:54.968(java.sql.Timestamp)][createdTxStamp,2008-12-05 19:30:54.875(java.sql.Timestamp)][lastUpdatedStamp,2008-12-18
05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp,2008-12-18 05:20:12.265
(java.sql.Timestamp)][productId,WG-5569(java.lang.String)][totalQuantityOrdered,4(java.lang.String)][totalTimesViewed,3(java.lang.Long)]
(SQL Exception while executing the following:UPDATE public.PRODUCT_CALC
ULATED_INFO SET TOTAL_QUANTITY_ORDERED=?, TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?, LAST_UPDATED_STAMP=?,
LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREUR: la col
onne ½ total_quantity_ordered + est de type double precision mais l'expression est de type character varying)). Rolling back
transaction.
Exception: org.ofbiz.entity.GenericEntityException
Message: Error while updating: [GenericEntity:ProductCalculatedInfo][averageCustomerRating,null()][createdStamp,2008-12-05
19:30:54.968(java.sql.Timestamp)][createdTxStamp,2008-12-05 19:30:54.875(java.sql.Tim
estamp)][lastUpdatedStamp,2008-12-18 05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp,2008-12-18
05:20:12.265(java.sql.Timestamp)][productId,WG-5569(java.lang.String)][totalQuantityOrdered,4(java.lang.Str
ing)][totalTimesViewed,3(java.lang.Long)] (SQL Exception while executing the following:UPDATE public.PRODUCT_CALCULATED_INFO SET
TOTAL_QUANTITY_ORDERED=?, TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?, LAST
_UPDATED_STAMP=?, LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREUR: la colonne ½
total_quantity_ordered + est de type double precision mais l'expression est de type char
acter varying))
---- cause ---------------------------------------------------------------------
Exception: org.ofbiz.entity.GenericDataSourceException
Message: SQL Exception while executing the following:UPDATE public.PRODUCT_CALCULATED_INFO SET TOTAL_QUANTITY_ORDERED=?,
TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?, LAST_UPDATED_STAMP=?, LAST_UPDATED_TX_
STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREUR: la colonne ½ total_quantity_ordered + est de type double
precision mais l'expression est de type character varying)
---- cause ---------------------------------------------------------------------
Exception: org.postgresql.util.PSQLException
Message: ERREUR: la colonne ½ total_quantity_ordered + est de type double precision mais l'expression est de type character varying
---- stack trace ---------------------------------------------------------------
org.postgresql.util.PSQLException: ERREUR: la colonne ½ total_quantity_ordered + est de type double precision mais l'expression est
de type character varying
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1592)
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1327)
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:192)
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350)
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:304)
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
org.ofbiz.entity.jdbc.SQLProcessor.executeUpdate(SQLProcessor.java:429)
org.ofbiz.entity.datasource.GenericDAO.singleUpdate(GenericDAO.java:270)
org.ofbiz.entity.datasource.GenericDAO.customUpdate(GenericDAO.java:211)
org.ofbiz.entity.datasource.GenericDAO.update(GenericDAO.java:205)
org.ofbiz.entity.datasource.GenericHelperDAO.store(GenericHelperDAO.java:172)
org.ofbiz.entity.GenericDelegator.store(GenericDelegator.java:1268)
org.ofbiz.minilang.method.entityops.StoreValue.exec(StoreValue.java:74)
org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
org.ofbiz.minilang.method.ifops.IfEmpty.exec(IfEmpty.java:98)
org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:749)
org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:149)
org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:131)
org.ofbiz.minilang.SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:76)
org.ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:51)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:384)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:213)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149)
org.ofbiz.order.order.OrderServices.createOrder(OrderServices.java:266)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:96)
org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:54)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:384)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:213)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149)
org.ofbiz.order.shoppingcart.CheckOutHelper.createOrder(CheckOutHelper.java:602)
org.ofbiz.order.shoppingcart.CheckOutEvents.createOrder(CheckOutEvents.java:434)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:89)
org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:75)
org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:456)
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:288)
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:204)
javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:259)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
org.ofbiz.catalina.container.CrossSubdomainSessionValve.invoke(CrossSubdomainSessionValve.java:42)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:595)
--------------------------------------------------------------------------------

2008-12-18 05:20:12,500 (http-0.0.0.0-18443-1) [    TransactionUtil.java:311:WARN ]
---- exception report ----------------------------------------------------------
[TransactionUtil.setRollbackOnly] Calling transaction setRollbackOnly; this stack trace shows where this is happening:
Exception: java.lang.Exception
Message: Failure in store operation for entity [ProductCalculatedInfo]: org.ofbiz.entity.GenericEntityException: Error while
updating: [GenericEntity:ProductCalculatedInfo][averageCustomerRating,null()][creat
edStamp,2008-12-05 19:30:54.968(java.sql.Timestamp)][createdTxStamp,2008-12-05
19:30:54.875(java.sql.Timestamp)][lastUpdatedStamp,2008-12-18 05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp,2008-12-18 05:
20:12.265(java.sql.Timestamp)][productId,WG-5569(java.lang.String)][totalQuantityOrdered,4(java.lang.String)][totalTimesViewed,3(java.lang.Long)]
(SQL Exception while executing the following:UPDATE public.PRO
DUCT_CALCULATED_INFO SET TOTAL_QUANTITY_ORDERED=?, TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?, LAST_UPDATED_STAMP=?,
LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREU
R: la colonne ½ total_quantity_ordered + est de type double precision mais l'expression est de type character varying)). Rolling
back transaction.

I guess At this stage BigDecimal or Double is the same (it will be sql-type="FLOAT8" anyway)

Jacques

From: "David E Jones" <[hidden email]>

>
> If that is the case then there must have been a different error  message than the one quoted in the first message by Akash:
>
> "DATABASE TYPE error IN GenericEntity.set In entity field   [OrderPaymentPreference.maxAmount] set the value passed in
> [java.math.BigDecimal] is not compatible with the Java type of the   field [Double]"
>
> That error comes from GenericEntity.java and there is no exception  thrown or anything that would cause a rollback.
>
> What was the error that caused the rollback? I'm thinking that it  would be best to use a type="BigDecimal", but I don't know
> because I  don't know what the problem was you were trying to fix...
>
> -David
>
>
> On Dec 17, 2008, at 7:34 AM, Jacques Le Roux wrote:
>
>> On Postgres it's not only a warning but really an error. The  transaction is rolled back and you can't create an order from
>> eCommerce without that change.
>> I used Double since that's what was used 3 lines above for the same  variable.
>> I just tried with BigDecimal, it works too. But I'm not sure it  makes more sense to use BigDecimal as it's about a quantity
>> (totalQuantityOrdered).
>> I never saw a rational quantity used but I guess Long would not fit  well here in case somebody would have the need for rational
>> quantities.
>> Do you want I put BigDecimal instead ?
>>
>> Jacques
>>
>> From: "David E Jones" <[hidden email]>
>>>
>>> That's a funny one, since the syntax used was not supported before  UEL  was introduced, and I mean the original line without
>>> your  change  Jacques. In other words this attribute would not work  without UEL:
>>>
>>> value="${productCalculatedInfo.totalQuantityOrdered +   parameters.quantity}"
>>>
>>> I guess somehow the type casting was missed so whatever UEL  defaults  to was used. If that was BigDecimal, then we should LEAVE
>>> it as  BigDecimal and not cast it to a Double. Yes, for now there  will be  warnings (which is all that the reported message
>>> was), but  there is a  separate branch that mostly Scott Gray is working on to  get everything  moved over from Double to
>>> BigDecimal, and until  then the warnings are  a good thing and we shouldn't try to fix  each one.
>>>
>>> For everyone, when you see that warning message just consider a   reminder that there is an effort going on to move from Double
>>> to  BigDecimal and without it there are issues in OFBiz, so your help  on  the effort will help you too.
>>>
>>> -David
>>>
>>>
>>> On Dec 16, 2008, at 11:21 AM, Jacques Le Roux wrote:
>>>
>>>> I got the same type of problem in OrderServices.createOrder  method  when calling service countProductQuantityOrdered
>>>> I changed the line
>>>> <set field="productCalculatedInfo.totalQuantityOrdered" value="$  {productCalculatedInfo.totalQuantityOrdered +
>>>> parameters.quantity}"/>
>>>> to
>>>> <set field="productCalculatedInfo.totalQuantityOrdered" value="$  {productCalculatedInfo.totalQuantityOrdered +
>>>> parameters.quantity}"
>>>> type="Double"/>
>>>>
>>>> I guess it's related to recent UEL change and, as David said, we   will cross a lot of same issues...
>>>>
>>>> Jacques
>>>>
>>>> From: "Akash Jain" <[hidden email]>
>>>>> Hello all,
>>>>>
>>>>> I am getting an exception when I submitted order in ecommerce.
>>>>>
>>>>> (1) First I add a product to cart.(add to cart)
>>>>> (2) Then click on checkout.(One Page Checkout)
>>>>> I am getting an exception like
>>>>>
>>>>> DATABASE TYPE error IN GenericEntity.set In entity field   [OrderPaymentPreference.maxAmount] set the value passed in
>>>>> [java.math.BigDecimal] is not compatible with the Java type of  the  field [Double]
>>>>>
>>>>> after submitting order.(Submit Order)
>>>>>
>>>>> ( I am working on  726678 Revision)
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>> Regards
>>>>> Akash Jain
>>>>> Hotwaxmedia Pvt. Ltd.
>>>>>
>>>>
>>
>

[David E Jones-3]

One way or another when this is passed to the database it should be a  
BigDecimal (quantities don't have to be whole numbers so we need  
Double or BigDecimal, and we definitely would want BigDecimal as  
Double isn't sufficiently accurate and rounding errors end up  
happening here and there.

It would be nice if UEL could return a BigDecimal whenever an  
expression involves an arithmetic operation (as well as what we were  
discussing in the other thread about telling UEL whether to allow and  
arithmetic operation or not, or whatever we can do with that to avoid  
the syntax problems... but that's another issue).

For now I like the idea of specifying the type of BigDecimal the best,  
and we'll see if we can improve things later (ie make them behave in a  
more friendly default way... like at least returning a numeric object  
of some sort instead of a String when there is an arithmetic operation  
in the expression).

-David


On Dec 17, 2008, at 9:24 PM, Jacques Le Roux wrote:

> Hi DAvid,
>
> Here is the error
>
> 2008-12-18 05:20:12,390 (http-0.0.0.0-18443-1)  
> [            UtilXml.java:241:INFO ] XML Read 0.047s: file:/D:/
> workspace/ofbizRun/applications/product/script/org/ofbiz/product/
> product/ProductServices.xml
> 2008-12-18 05:20:12,484 (http-0.0.0.0-18443-1)  
> [   GenericDelegator.java:1280:ERROR]
> ---- exception report  
> ----------------------------------------------------------
> Failure in store operation for entity [ProductCalculatedInfo]:  
> org.ofbiz.entity.GenericEntityException: Error while updating:  
> [GenericEntity:ProductCalculatedInfo][averageCustomerRating,null()]
> [createdStamp,2
> 008-12-05 19:30:54.968(java.sql.Timestamp)][createdTxStamp,
> 2008-12-05 19:30:54.875(java.sql.Timestamp)][lastUpdatedStamp,
> 2008-12-18 05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp,
> 2008-12-18 05:20:12.265
> (java.sql.Timestamp)][productId,WG-5569(java.lang.String)]
> [totalQuantityOrdered,4(java.lang.String)][totalTimesViewed,
> 3(java.lang.Long)] (SQL Exception while executing the  
> following:UPDATE public.PRODUCT_CALC
> ULATED_INFO SET TOTAL_QUANTITY_ORDERED=?, TOTAL_TIMES_VIEWED=?,  
> AVERAGE_CUSTOMER_RATING=?, LAST_UPDATED_STAMP=?,  
> LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE  
> PRODUCT_ID=? (ERREUR: la col
> onne ½ total_quantity_ordered + est de type double precision mais  
> l'expression est de type character varying)). Rolling back  
> transaction.
> Exception: org.ofbiz.entity.GenericEntityException
> Message: Error while updating: [GenericEntity:ProductCalculatedInfo]
> [averageCustomerRating,null()][createdStamp,2008-12-05  
> 19:30:54.968(java.sql.Timestamp)][createdTxStamp,2008-12-05  
> 19:30:54.875(java.sql.Tim
> estamp)][lastUpdatedStamp,2008-12-18  
> 05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp,2008-12-18  
> 05:20:12.265(java.sql.Timestamp)]
> [productId,WG-5569(java.lang.String)][totalQuantityOrdered,
> 4(java.lang.Str
> ing)][totalTimesViewed,3(java.lang.Long)] (SQL Exception while  
> executing the following:UPDATE public.PRODUCT_CALCULATED_INFO SET  
> TOTAL_QUANTITY_ORDERED=?, TOTAL_TIMES_VIEWED=?,  
> AVERAGE_CUSTOMER_RATING=?, LAST
> _UPDATED_STAMP=?, LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?,  
> CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREUR: la colonne ½  
> total_quantity_ordered + est de type double precision mais  
> l'expression est de type char
> acter varying))
> ---- cause  
> ---------------------------------------------------------------------
> Exception: org.ofbiz.entity.GenericDataSourceException
> Message: SQL Exception while executing the following:UPDATE  
> public.PRODUCT_CALCULATED_INFO SET TOTAL_QUANTITY_ORDERED=?,  
> TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?,  
> LAST_UPDATED_STAMP=?, LAST_UPDATED_TX_
> STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE PRODUCT_ID=?  
> (ERREUR: la colonne ½ total_quantity_ordered + est de type double  
> precision mais l'expression est de type character varying)
> ---- cause  
> ---------------------------------------------------------------------
> Exception: org.postgresql.util.PSQLException
> Message: ERREUR: la colonne ½ total_quantity_ordered + est de type  
> double precision mais l'expression est de type character varying
> ---- stack trace  
> ---------------------------------------------------------------
> org.postgresql.util.PSQLException: ERREUR: la colonne ½  
> total_quantity_ordered + est de type double precision mais  
> l'expression est de type character varying
> org
> .postgresql
> .core
> .v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:
> 1592)
> org
> .postgresql
> .core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1327)
> org
> .postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:
> 192)
> org
> .postgresql
> .jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
> org
> .postgresql
> .jdbc2
> .AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:
> 350)
> org
> .postgresql
> .jdbc2
> .AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:304)
> org
> .apache
> .commons
> .dbcp
> .DelegatingPreparedStatement
> .executeUpdate(DelegatingPreparedStatement.java:102)
> org
> .apache
> .commons
> .dbcp
> .DelegatingPreparedStatement
> .executeUpdate(DelegatingPreparedStatement.java:102)
> org.ofbiz.entity.jdbc.SQLProcessor.executeUpdate(SQLProcessor.java:
> 429)
> org.ofbiz.entity.datasource.GenericDAO.singleUpdate(GenericDAO.java:
> 270)
> org.ofbiz.entity.datasource.GenericDAO.customUpdate(GenericDAO.java:
> 211)
> org.ofbiz.entity.datasource.GenericDAO.update(GenericDAO.java:205)
> org
> .ofbiz
> .entity.datasource.GenericHelperDAO.store(GenericHelperDAO.java:172)
> org.ofbiz.entity.GenericDelegator.store(GenericDelegator.java:1268)
> org.ofbiz.minilang.method.entityops.StoreValue.exec(StoreValue.java:
> 74)
> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
> org.ofbiz.minilang.method.ifops.IfEmpty.exec(IfEmpty.java:98)
> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
> org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:749)
> org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:149)
> org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:
> 131)
> org
> .ofbiz
> .minilang
> .SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:76)
> org
> .ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:
> 51)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 384)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 213)
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:
> 149)
> org.ofbiz.order.order.OrderServices.createOrder(OrderServices.java:
> 266)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org
> .ofbiz
> .service
> .engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:96)
> org
> .ofbiz
> .service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:54)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 384)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 213)
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:
> 149)
> org
> .ofbiz
> .order.shoppingcart.CheckOutHelper.createOrder(CheckOutHelper.java:
> 602)
> org
> .ofbiz
> .order.shoppingcart.CheckOutEvents.createOrder(CheckOutEvents.java:
> 434)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:
> 89)
> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:
> 75)
> org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:
> 456)
> org
> .ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:
> 288)
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:204)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> org
> .apache
> .catalina
> .core
> .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> 290)
> org
> .apache
> .catalina
> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:
> 259)
> org
> .apache
> .catalina
> .core
> .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> 235)
> org
> .apache
> .catalina
> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> org
> .apache
> .catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
> 233)
> org
> .apache
> .catalina.core.StandardContextValve.invoke(StandardContextValve.java:
> 175)
> org
> .apache
> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> org
> .apache
> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> org
> .apache
> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
> 109)
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> 568)
> org
> .ofbiz
> .catalina
> .container
> .CrossSubdomainSessionValve.invoke(CrossSubdomainSessionValve.java:42)
> org
> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> 286)
> org
> .apache.coyote.http11.Http11Processor.process(Http11Processor.java:
> 844)
> org.apache.coyote.http11.Http11Protocol
> $Http11ConnectionHandler.process(Http11Protocol.java:583)
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
> 447)
> java.lang.Thread.run(Thread.java:595)
> --------------------------------------------------------------------------------
>
> 2008-12-18 05:20:12,500 (http-0.0.0.0-18443-1)  
> [    TransactionUtil.java:311:WARN ]
> ---- exception report  
> ----------------------------------------------------------
> [TransactionUtil.setRollbackOnly] Calling transaction  
> setRollbackOnly; this stack trace shows where this is happening:
> Exception: java.lang.Exception
> Message: Failure in store operation for entity  
> [ProductCalculatedInfo]: org.ofbiz.entity.GenericEntityException:  
> Error while updating: [GenericEntity:ProductCalculatedInfo]
> [averageCustomerRating,null()][creat
> edStamp,2008-12-05 19:30:54.968(java.sql.Timestamp)][createdTxStamp,
> 2008-12-05 19:30:54.875(java.sql.Timestamp)][lastUpdatedStamp,
> 2008-12-18 05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp,
> 2008-12-18 05:
> 20:12.265(java.sql.Timestamp)][productId,WG-5569(java.lang.String)]
> [totalQuantityOrdered,4(java.lang.String)][totalTimesViewed,
> 3(java.lang.Long)] (SQL Exception while executing the  
> following:UPDATE public.PRO
> DUCT_CALCULATED_INFO SET TOTAL_QUANTITY_ORDERED=?,  
> TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?,  
> LAST_UPDATED_STAMP=?, LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?,  
> CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREU
> R: la colonne ½ total_quantity_ordered + est de type double  
> precision mais l'expression est de type character varying)). Rolling  
> back transaction.
>
> I guess At this stage BigDecimal or Double is the same (it will be  
> sql-type="FLOAT8" anyway)
>
> Jacques
>
> From: "David E Jones" <[hidden email]>
>>
>> If that is the case then there must have been a different error  
>> message than the one quoted in the first message by Akash:
>>
>> "DATABASE TYPE error IN GenericEntity.set In entity field    
>> [OrderPaymentPreference.maxAmount] set the value passed in  
>> [java.math.BigDecimal] is not compatible with the Java type of  
>> the   field [Double]"
>>
>> That error comes from GenericEntity.java and there is no exception  
>> thrown or anything that would cause a rollback.
>>
>> What was the error that caused the rollback? I'm thinking that it  
>> would be best to use a type="BigDecimal", but I don't know because  
>> I  don't know what the problem was you were trying to fix...
>>
>> -David
>>
>>
>> On Dec 17, 2008, at 7:34 AM, Jacques Le Roux wrote:
>>
>>> On Postgres it's not only a warning but really an error. The  
>>> transaction is rolled back and you can't create an order from  
>>> eCommerce without that change.
>>> I used Double since that's what was used 3 lines above for the  
>>> same  variable.
>>> I just tried with BigDecimal, it works too. But I'm not sure it  
>>> makes more sense to use BigDecimal as it's about a quantity  
>>> (totalQuantityOrdered).
>>> I never saw a rational quantity used but I guess Long would not  
>>> fit  well here in case somebody would have the need for rational  
>>> quantities.
>>> Do you want I put BigDecimal instead ?
>>>
>>> Jacques
>>>
>>> From: "David E Jones" <[hidden email]>
>>>>
>>>> That's a funny one, since the syntax used was not supported  
>>>> before  UEL  was introduced, and I mean the original line without  
>>>> your  change  Jacques. In other words this attribute would not  
>>>> work  without UEL:
>>>>
>>>> value="${productCalculatedInfo.totalQuantityOrdered +    
>>>> parameters.quantity}"
>>>>
>>>> I guess somehow the type casting was missed so whatever UEL  
>>>> defaults  to was used. If that was BigDecimal, then we should  
>>>> LEAVE it as  BigDecimal and not cast it to a Double. Yes, for now  
>>>> there  will be  warnings (which is all that the reported message  
>>>> was), but  there is a  separate branch that mostly Scott Gray is  
>>>> working on to  get everything  moved over from Double to  
>>>> BigDecimal, and until  then the warnings are  a good thing and we  
>>>> shouldn't try to fix  each one.
>>>>
>>>> For everyone, when you see that warning message just consider a    
>>>> reminder that there is an effort going on to move from Double to  
>>>> BigDecimal and without it there are issues in OFBiz, so your  
>>>> help  on  the effort will help you too.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Dec 16, 2008, at 11:21 AM, Jacques Le Roux wrote:
>>>>
>>>>> I got the same type of problem in OrderServices.createOrder  
>>>>> method  when calling service countProductQuantityOrdered
>>>>> I changed the line
>>>>> <set field="productCalculatedInfo.totalQuantityOrdered"  
>>>>> value="$  {productCalculatedInfo.totalQuantityOrdered +  
>>>>> parameters.quantity}"/>
>>>>> to
>>>>> <set field="productCalculatedInfo.totalQuantityOrdered"  
>>>>> value="$  {productCalculatedInfo.totalQuantityOrdered +  
>>>>> parameters.quantity}"
>>>>> type="Double"/>
>>>>>
>>>>> I guess it's related to recent UEL change and, as David said,  
>>>>> we   will cross a lot of same issues...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Akash Jain" <[hidden email]>
>>>>>> Hello all,
>>>>>>
>>>>>> I am getting an exception when I submitted order in ecommerce.
>>>>>>
>>>>>> (1) First I add a product to cart.(add to cart)
>>>>>> (2) Then click on checkout.(One Page Checkout)
>>>>>> I am getting an exception like
>>>>>>
>>>>>> DATABASE TYPE error IN GenericEntity.set In entity field    
>>>>>> [OrderPaymentPreference.maxAmount] set the value passed in
>>>>>> [java.math.BigDecimal] is not compatible with the Java type of  
>>>>>> the  field [Double]
>>>>>>
>>>>>> after submitting order.(Submit Order)
>>>>>>
>>>>>> ( I am working on  726678 Revision)
>>>>>>
>>>>>> Thanks in advance
>>>>>>
>>>>>> Regards
>>>>>> Akash Jain
>>>>>> Hotwaxmedia Pvt. Ltd.
>>>>>>
>>>>>
>>>
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
>
> One way or another when this is passed to the database it should be a  BigDecimal (quantities don't have to be whole numbers so we
> need  Double or BigDecimal, and we definitely would want BigDecimal as  Double isn't sufficiently accurate and rounding errors end
> up  happening here and there.

Done in revision: 727783

> It would be nice if UEL could return a BigDecimal whenever an  expression involves an arithmetic operation (as well as what we
> were  discussing in the other thread about telling UEL whether to allow and  arithmetic operation or not, or whatever we can do
> with that to avoid  the syntax problems... but that's another issue).
>
> For now I like the idea of specifying the type of BigDecimal the best,  and we'll see if we can improve things later (ie make them
> behave in a  more friendly default way... like at least returning a numeric object  of some sort instead of a String when there is
> an arithmetic operation  in the expression).

Yes but there is also this conflict when using name/id like GIZMO-3644, like you said just above

Jacques

> -David
>
>
> On Dec 17, 2008, at 9:24 PM, Jacques Le Roux wrote:
>
>> Hi DAvid,
>>
>> Here is the error
>>
>> 2008-12-18 05:20:12,390 (http-0.0.0.0-18443-1)  [            UtilXml.java:241:INFO ] XML Read 0.047s: file:/D:/
>> workspace/ofbizRun/applications/product/script/org/ofbiz/product/ product/ProductServices.xml
>> 2008-12-18 05:20:12,484 (http-0.0.0.0-18443-1)  [   GenericDelegator.java:1280:ERROR]
>> ---- exception report  ----------------------------------------------------------
>> Failure in store operation for entity [ProductCalculatedInfo]:  org.ofbiz.entity.GenericEntityException: Error while updating:
>> [GenericEntity:ProductCalculatedInfo][averageCustomerRating,null()] [createdStamp,2
>> 008-12-05 19:30:54.968(java.sql.Timestamp)][createdTxStamp, 2008-12-05 19:30:54.875(java.sql.Timestamp)][lastUpdatedStamp,
>> 2008-12-18 05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp, 2008-12-18 05:20:12.265
>> (java.sql.Timestamp)][productId,WG-5569(java.lang.String)] [totalQuantityOrdered,4(java.lang.String)][totalTimesViewed,
>> 3(java.lang.Long)] (SQL Exception while executing the  following:UPDATE public.PRODUCT_CALC
>> ULATED_INFO SET TOTAL_QUANTITY_ORDERED=?, TOTAL_TIMES_VIEWED=?,  AVERAGE_CUSTOMER_RATING=?, LAST_UPDATED_STAMP=?,
>> LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE  PRODUCT_ID=? (ERREUR: la col
>> onne ½ total_quantity_ordered + est de type double precision mais  l'expression est de type character varying)). Rolling back
>> transaction.
>> Exception: org.ofbiz.entity.GenericEntityException
>> Message: Error while updating: [GenericEntity:ProductCalculatedInfo] [averageCustomerRating,null()][createdStamp,2008-12-05
>> 19:30:54.968(java.sql.Timestamp)][createdTxStamp,2008-12-05  19:30:54.875(java.sql.Tim
>> estamp)][lastUpdatedStamp,2008-12-18  05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp,2008-12-18
>> 05:20:12.265(java.sql.Timestamp)] [productId,WG-5569(java.lang.String)][totalQuantityOrdered, 4(java.lang.Str
>> ing)][totalTimesViewed,3(java.lang.Long)] (SQL Exception while  executing the following:UPDATE public.PRODUCT_CALCULATED_INFO SET
>> TOTAL_QUANTITY_ORDERED=?, TOTAL_TIMES_VIEWED=?,  AVERAGE_CUSTOMER_RATING=?, LAST
>> _UPDATED_STAMP=?, LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?,  CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREUR: la colonne ½
>> total_quantity_ordered + est de type double precision mais  l'expression est de type char
>> acter varying))
>> ---- cause  ---------------------------------------------------------------------
>> Exception: org.ofbiz.entity.GenericDataSourceException
>> Message: SQL Exception while executing the following:UPDATE  public.PRODUCT_CALCULATED_INFO SET TOTAL_QUANTITY_ORDERED=?,
>> TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?,  LAST_UPDATED_STAMP=?, LAST_UPDATED_TX_
>> STAMP=?, CREATED_STAMP=?, CREATED_TX_STAMP=? WHERE PRODUCT_ID=?  (ERREUR: la colonne ½ total_quantity_ordered + est de type
>> double  precision mais l'expression est de type character varying)
>> ---- cause  ---------------------------------------------------------------------
>> Exception: org.postgresql.util.PSQLException
>> Message: ERREUR: la colonne ½ total_quantity_ordered + est de type  double precision mais l'expression est de type character
>> varying
>> ---- stack trace  ---------------------------------------------------------------
>> org.postgresql.util.PSQLException: ERREUR: la colonne ½  total_quantity_ordered + est de type double precision mais  l'expression
>> est de type character varying
>> org .postgresql .core .v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java: 1592)
>> org .postgresql .core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1327)
>> org .postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java: 192)
>> org .postgresql .jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
>> org .postgresql .jdbc2 .AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java: 350)
>> org .postgresql .jdbc2 .AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:304)
>> org .apache .commons .dbcp .DelegatingPreparedStatement .executeUpdate(DelegatingPreparedStatement.java:102)
>> org .apache .commons .dbcp .DelegatingPreparedStatement .executeUpdate(DelegatingPreparedStatement.java:102)
>> org.ofbiz.entity.jdbc.SQLProcessor.executeUpdate(SQLProcessor.java: 429)
>> org.ofbiz.entity.datasource.GenericDAO.singleUpdate(GenericDAO.java: 270)
>> org.ofbiz.entity.datasource.GenericDAO.customUpdate(GenericDAO.java: 211)
>> org.ofbiz.entity.datasource.GenericDAO.update(GenericDAO.java:205)
>> org .ofbiz .entity.datasource.GenericHelperDAO.store(GenericHelperDAO.java:172)
>> org.ofbiz.entity.GenericDelegator.store(GenericDelegator.java:1268)
>> org.ofbiz.minilang.method.entityops.StoreValue.exec(StoreValue.java: 74)
>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>> org.ofbiz.minilang.method.ifops.IfEmpty.exec(IfEmpty.java:98)
>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>> org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:749)
>> org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:149)
>> org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java: 131)
>> org .ofbiz .minilang .SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:76)
>> org .ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java: 51)
>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java: 384)
>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java: 213)
>> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java: 149)
>> org.ofbiz.order.order.OrderServices.createOrder(OrderServices.java: 266)
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25)
>> java.lang.reflect.Method.invoke(Method.java:585)
>> org .ofbiz .service .engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:96)
>> org .ofbiz .service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:54)
>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java: 384)
>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java: 213)
>> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java: 149)
>> org .ofbiz .order.shoppingcart.CheckOutHelper.createOrder(CheckOutHelper.java: 602)
>> org .ofbiz .order.shoppingcart.CheckOutEvents.createOrder(CheckOutEvents.java: 434)
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25)
>> java.lang.reflect.Method.invoke(Method.java:585)
>> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java: 89)
>> org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java: 75)
>> org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java: 456)
>> org .ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java: 288)
>> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:204)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> org .apache .catalina .core .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 290)
>> org .apache .catalina .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java: 259)
>> org .apache .catalina .core .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 235)
>> org .apache .catalina .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> org .apache .catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: 233)
>> org .apache .catalina.core.StandardContextValve.invoke(StandardContextValve.java: 175)
>> org .apache .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>> org .apache .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>> org .apache .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: 109)
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 568)
>> org .ofbiz .catalina .container .CrossSubdomainSessionValve.invoke(CrossSubdomainSessionValve.java:42)
>> org .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 286)
>> org .apache.coyote.http11.Http11Processor.process(Http11Processor.java: 844)
>> org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:583)
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java: 447)
>> java.lang.Thread.run(Thread.java:595)
>> --------------------------------------------------------------------------------
>>
>> 2008-12-18 05:20:12,500 (http-0.0.0.0-18443-1)  [    TransactionUtil.java:311:WARN ]
>> ---- exception report  ----------------------------------------------------------
>> [TransactionUtil.setRollbackOnly] Calling transaction  setRollbackOnly; this stack trace shows where this is happening:
>> Exception: java.lang.Exception
>> Message: Failure in store operation for entity  [ProductCalculatedInfo]: org.ofbiz.entity.GenericEntityException:  Error while
>> updating: [GenericEntity:ProductCalculatedInfo] [averageCustomerRating,null()][creat
>> edStamp,2008-12-05 19:30:54.968(java.sql.Timestamp)][createdTxStamp, 2008-12-05
>> 19:30:54.875(java.sql.Timestamp)][lastUpdatedStamp, 2008-12-18 05:20:12.484(java.sql.Timestamp)][lastUpdatedTxStamp, 2008-12-18
>> 05:
>> 20:12.265(java.sql.Timestamp)][productId,WG-5569(java.lang.String)] [totalQuantityOrdered,4(java.lang.String)][totalTimesViewed,
>> 3(java.lang.Long)] (SQL Exception while executing the  following:UPDATE public.PRO
>> DUCT_CALCULATED_INFO SET TOTAL_QUANTITY_ORDERED=?,  TOTAL_TIMES_VIEWED=?, AVERAGE_CUSTOMER_RATING=?,  LAST_UPDATED_STAMP=?,
>> LAST_UPDATED_TX_STAMP=?, CREATED_STAMP=?,  CREATED_TX_STAMP=? WHERE PRODUCT_ID=? (ERREU
>> R: la colonne ½ total_quantity_ordered + est de type double  precision mais l'expression est de type character varying)). Rolling
>> back transaction.
>>
>> I guess At this stage BigDecimal or Double is the same (it will be  sql-type="FLOAT8" anyway)
>>
>> Jacques
>>
>> From: "David E Jones" <[hidden email]>
>>>
>>> If that is the case then there must have been a different error   message than the one quoted in the first message by Akash:
>>>
>>> "DATABASE TYPE error IN GenericEntity.set In entity field    [OrderPaymentPreference.maxAmount] set the value passed in
>>> [java.math.BigDecimal] is not compatible with the Java type of  the   field [Double]"
>>>
>>> That error comes from GenericEntity.java and there is no exception   thrown or anything that would cause a rollback.
>>>
>>> What was the error that caused the rollback? I'm thinking that it   would be best to use a type="BigDecimal", but I don't know
>>> because  I  don't know what the problem was you were trying to fix...
>>>
>>> -David
>>>
>>>
>>> On Dec 17, 2008, at 7:34 AM, Jacques Le Roux wrote:
>>>
>>>> On Postgres it's not only a warning but really an error. The   transaction is rolled back and you can't create an order from
>>>> eCommerce without that change.
>>>> I used Double since that's what was used 3 lines above for the  same  variable.
>>>> I just tried with BigDecimal, it works too. But I'm not sure it   makes more sense to use BigDecimal as it's about a quantity
>>>> (totalQuantityOrdered).
>>>> I never saw a rational quantity used but I guess Long would not  fit  well here in case somebody would have the need for
>>>> rational  quantities.
>>>> Do you want I put BigDecimal instead ?
>>>>
>>>> Jacques
>>>>
>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>> That's a funny one, since the syntax used was not supported  before  UEL  was introduced, and I mean the original line without
>>>>> your  change  Jacques. In other words this attribute would not  work  without UEL:
>>>>>
>>>>> value="${productCalculatedInfo.totalQuantityOrdered +    parameters.quantity}"
>>>>>
>>>>> I guess somehow the type casting was missed so whatever UEL   defaults  to was used. If that was BigDecimal, then we should
>>>>> LEAVE it as  BigDecimal and not cast it to a Double. Yes, for now  there  will be  warnings (which is all that the reported
>>>>> message  was), but  there is a  separate branch that mostly Scott Gray is  working on to  get everything  moved over from
>>>>> Double to  BigDecimal, and until  then the warnings are  a good thing and we  shouldn't try to fix  each one.
>>>>>
>>>>> For everyone, when you see that warning message just consider a    reminder that there is an effort going on to move from
>>>>> Double to   BigDecimal and without it there are issues in OFBiz, so your  help  on  the effort will help you too.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Dec 16, 2008, at 11:21 AM, Jacques Le Roux wrote:
>>>>>
>>>>>> I got the same type of problem in OrderServices.createOrder   method  when calling service countProductQuantityOrdered
>>>>>> I changed the line
>>>>>> <set field="productCalculatedInfo.totalQuantityOrdered"  value="$  {productCalculatedInfo.totalQuantityOrdered +
>>>>>> parameters.quantity}"/>
>>>>>> to
>>>>>> <set field="productCalculatedInfo.totalQuantityOrdered"  value="$  {productCalculatedInfo.totalQuantityOrdered +
>>>>>> parameters.quantity}"
>>>>>> type="Double"/>
>>>>>>
>>>>>> I guess it's related to recent UEL change and, as David said,  we   will cross a lot of same issues...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Akash Jain" <[hidden email]>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I am getting an exception when I submitted order in ecommerce.
>>>>>>>
>>>>>>> (1) First I add a product to cart.(add to cart)
>>>>>>> (2) Then click on checkout.(One Page Checkout)
>>>>>>> I am getting an exception like
>>>>>>>
>>>>>>> DATABASE TYPE error IN GenericEntity.set In entity field    [OrderPaymentPreference.maxAmount] set the value passed in
>>>>>>> [java.math.BigDecimal] is not compatible with the Java type of   the  field [Double]
>>>>>>>
>>>>>>> after submitting order.(Submit Order)
>>>>>>>
>>>>>>> ( I am working on  726678 Revision)
>>>>>>>
>>>>>>> Thanks in advance
>>>>>>>
>>>>>>> Regards
>>>>>>> Akash Jain
>>>>>>> Hotwaxmedia Pvt. Ltd.
>>>>>>>
>>>>>>
>>>>
>>
>
>

[David E Jones-3]

On Dec 18, 2008, at 11:29 AM, Jacques Le Roux wrote:

> From: "David E Jones" <[hidden email]>
>> It would be nice if UEL could return a BigDecimal whenever an  
>> expression involves an arithmetic operation (as well as what we
>> were  discussing in the other thread about telling UEL whether to  
>> allow and  arithmetic operation or not, or whatever we can do
>> with that to avoid  the syntax problems... but that's another issue).
>>
>> For now I like the idea of specifying the type of BigDecimal the  
>> best,  and we'll see if we can improve things later (ie make them
>> behave in a  more friendly default way... like at least returning a  
>> numeric object  of some sort instead of a String when there is
>> an arithmetic operation  in the expression).
>
> Yes but there is also this conflict when using name/id like  
> GIZMO-3644, like you said just above

For now just do what I did for the StockMoveServices.xml file: use the  
[""] (square-brace, quote) syntax instead of the . (dot) syntax.

In fact, while this hasn't been fully explored (Adrian is working on  
it and others may be too), my prediction is that in order to take  
advantage of the new features of UEL we'll have to stop using  
ambiguous syntax like the dot syntax whenever there is a change of a  
special character, like a - (dash), in the expression. Otherwise the  
parser doesn't know the difference. It's progress but it has plusses  
and minuses.

-David

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>

>
> On Dec 18, 2008, at 11:29 AM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>> It would be nice if UEL could return a BigDecimal whenever an  
>>> expression involves an arithmetic operation (as well as what we
>>> were  discussing in the other thread about telling UEL whether to  
>>> allow and  arithmetic operation or not, or whatever we can do
>>> with that to avoid  the syntax problems... but that's another issue).
>>>
>>> For now I like the idea of specifying the type of BigDecimal the  
>>> best,  and we'll see if we can improve things later (ie make them
>>> behave in a  more friendly default way... like at least returning a  
>>> numeric object  of some sort instead of a String when there is
>>> an arithmetic operation  in the expression).
>>
>> Yes but there is also this conflict when using name/id like  
>> GIZMO-3644, like you said just above
>
> For now just do what I did for the StockMoveServices.xml file: use the  
> [""] (square-brace, quote) syntax instead of the . (dot) syntax.
>
> In fact, while this hasn't been fully explored (Adrian is working on  
> it and others may be too), my prediction is that in order to take  
> advantage of the new features of UEL we'll have to stop using  
> ambiguous syntax like the dot syntax whenever there is a change of a  
> special character, like a - (dash), in the expression. Otherwise the  
> parser doesn't know the difference. It's progress but it has plusses  
> and minuses.

Understood, did you try to use simple quote (ie ') instead of &quot; ?

Jacques
 
> -David
>
>

[Adrian Crum]

David E Jones wrote:

>
> On Dec 18, 2008, at 11:29 AM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>> It would be nice if UEL could return a BigDecimal whenever an  
>>> expression involves an arithmetic operation (as well as what we
>>> were  discussing in the other thread about telling UEL whether to
>>> allow and  arithmetic operation or not, or whatever we can do
>>> with that to avoid  the syntax problems... but that's another issue).
>>>
>>> For now I like the idea of specifying the type of BigDecimal the
>>> best,  and we'll see if we can improve things later (ie make them
>>> behave in a  more friendly default way... like at least returning a
>>> numeric object  of some sort instead of a String when there is
>>> an arithmetic operation  in the expression).
>>
>> Yes but there is also this conflict when using name/id like
>> GIZMO-3644, like you said just above
>
> For now just do what I did for the StockMoveServices.xml file: use the
> [""] (square-brace, quote) syntax instead of the . (dot) syntax.
>
> In fact, while this hasn't been fully explored (Adrian is working on it
> and others may be too), my prediction is that in order to take advantage
> of the new features of UEL we'll have to stop using ambiguous syntax
> like the dot syntax whenever there is a change of a special character,
> like a - (dash), in the expression. Otherwise the parser doesn't know
> the difference. It's progress but it has plusses and minuses.

I'm making progress. The square braces won't need quotes when I get it
committed.

-Adrian