This could be related https://issues.apache.org/jira/browse/OFBIZ-6386 (did not
check anything, just a souvenir)
Jacques
Le 19/09/2016 à 16:20, Rishi Solanki a écrit :
Nicolas,
"If you are dealing with money, or precision is a must, use BigDecimal.
Otherwise Doubles tend to be good enough." That means, for quantity fields
double should be fine. But within OFBiz, I see entities like OrderItem,
OISGIR, and many other uses BigDecimal for quantity field. But I think that
is because in orderred quantity due to Product.orderDecimalQuantity user
may enter the decimal quantity.
With all this said, if we think WorkEffortGoodStandard.estimatedQuantity
may contains precision values in it in some business scenarios then we
should go for the #3. Or simple conversion should work as you suggested in
#1.
My suggestion is to go with #1, as I couldn't think of scenario where
precision required upto many decimal places for the
WorkEffortGoodStandard.estimatedQuantity field.
Hope its not too late for original topic in this thread, +1 for using the
same transaction for the permission services. As whenever we call
permission service in a wrapper service we always use the same transaction.
Thanks!
Best Regards,
--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
On Sat, Sep 17, 2016 at 5:30 PM, Nicolas Malin <nicolas.ma...@nereide.fr>
wrote:
Hi all, I need some Help !! I put my arm in a gearing :(
After refactor the permission service, I raise a silent problem that is
all call-service used on mini-lang test didn't passed to service validation.
I correct some easier case like bad attribut passed but now rest some
complicate case like this :
testProductionRunCreation : Type check failed for field
[createWorkEffortGoodStandard.estimatedQuantity]; expected type is
[Double]; actual type is [java.math.BigDecimal]
The problem came from that :
* Field has define as BigDecimal on mini-lang
* The service definition use auto-attribute to resolve the java type
* The field on the entity is define as floating-point and is converted by
fieldType as Double
So to reallign this I have some possibility
1. Easy : test are wrong : convert field instantiation to Double instead
of BigDecimal for all tests failed
2. Medium : service need realign : I surcharge attribute definition to
accept BigDecimal for these service
3. Hard : Why Double for floating-point, I had in my mind that BigDecimal
would be preferred to Double if is the case, we can change all fieldType
conversion to BigDecimal instead of Double and realign all ofbiz code
related.
Your suggest will be truly appreciated ;)
Nicolas
Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :
Hi Nicolas,
I have to note that in ModelPermission the same exact call is also made
with a new transaction. I did not dig deep into it but I advice to at
least
check it over there as well. This makes me suspect that either both call
are wrong or both calls are right.
HTH
Taher Alkhateeb
On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
pranay.pan...@hotwaxsystems.com> wrote:
Hi Nicolas,
Calling it as permission service is tricky. I see the comment in
implementation above the simple method in ShipmentServices.xml-
<!-- Check the Status of a Shipment to see if it can be changed -
meant to be called in-line -->
It was implemented with a purpose to be called inline, may be supporting
the traditional way of doing things. Reviewing at a complete patch with
all
the modifications you have done for making shipment CRUD operations can
help here getting the opinion. WDYT?
Best regards,
Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/
On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <nicolas.ma...@nereide.fr>
wrote:
Hello,
Currently I continue the conversion on shipment crud service and I
detected that many service use the same mini-lang call to check if the
shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
I convert it on service to call it directly by the permission-service
like that :
<service name="createShipmentPackageContent"
default-entity-name="ShipmentPackageContent" engine="entity-auto"
invoke="create" auth="true">...
<permission-service
service-name="checkCanChangeShipmentStatusPacked"
main-action="CREATE"/>
<auto-attributes include="pk" mode="IN" optional="false"/>...
</service>
The problem with this change that when I run the unit tests, I have some
failed to due database lock on shipment.
After some analyse I founded that the permission service wasn't call on
the same service's transaction.
I a realize this change :
Index: framework/service/src/org/ofbiz/service/ModelService.java
===================================================================
--- framework/service/src/org/ofbiz/service/ModelService.java
(révision 1737860)
+++ framework/service/src/org/ofbiz/service/ModelService.java (copie
de travail)
@@ -985,7 +985,7 @@
LocalDispatcher dispatcher = dctx.getDispatcher();
Map<String, Object> resp;
try {
- resp = dispatcher.runSync(permission.name, ctx,
300, true);
+ resp = dispatcher.runSync(permission.name, ctx);
} catch (GenericServiceException e) {
Debug.logError(e, module);
Map<String, Object> result =
ServiceUtil.returnSuccess();
All unit test pass.
Anyone know the reason to call the permission service on a new
transaction ?
I couldn't spot any valid reason.
Thnaks for help ;)
Nicolas
--
#jeSuisCharlie
[image: logoNrd] <http://nereide.fr/>
Nicolas Malin
Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent
trouver la sortie d'un labyrinthe en cas de toxoplasmose
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54
Apache OFBiz <http://ofbiz.apache.org/> | ofbiz-fr
<http://www.ofbiz-fr.org/> | | réseau LE
<http://www.libre-entreprise.org/>
