OFBiz
  1. OFBiz
  2. OFBIZ-3700

Convert WorkEffort (and related entities) quantities from Double -> BigDecimal

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: SVN trunk
    • Fix Version/s: SVN trunk
    • Component/s: workeffort
    • Labels:
      None

      Description

      It appears that this entity was missed from the BigDecimal conversion. Ran into this when ProductionRunServices was attempting to create a WorkEffort (it is passing the quantity to produce as a BigDecimal). A different bug in OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double (which was allowing ProductionRuns to be created). At any rate, we should convert this entity and any other quantity related entities in the WorkEffort component.

        Activity

        Hide
        Adrian Crum added a comment -

        Bob,

        What do you mean by converting the WorkEffort entity to BigDecimal?

        Show
        Adrian Crum added a comment - Bob, What do you mean by converting the WorkEffort entity to BigDecimal?
        Hide
        Bob Morley added a comment -

        Adrian - this is referring to the quantities on WorkEffort (and any WorkEffort related entities) such as the quantityToProduce ... quantities is in the title but perhaps it was abstracted by the "and related entities".

        Show
        Bob Morley added a comment - Adrian - this is referring to the quantities on WorkEffort (and any WorkEffort related entities) such as the quantityToProduce ... quantities is in the title but perhaps it was abstracted by the "and related entities".
        Hide
        Adrian Crum added a comment -

        I'm still lost. The WorkEffort entity definition doesn't specify Double for field types, only "floating-point", "currency-amount", "numeric", etc. Maybe you are referring to service definitions?

        Show
        Adrian Crum added a comment - I'm still lost. The WorkEffort entity definition doesn't specify Double for field types, only "floating-point", "currency-amount", "numeric", etc. Maybe you are referring to service definitions?
        Hide
        Bob Morley added a comment -

        Right and in the fieldtypepostgres.xml ...

        <field-type-def type="fixed-point" sql-type="NUMERIC(18,6)" java-type="java.math.BigDecimal"><validate method="isSignedDouble"/></field-type-def>
        <field-type-def type="floating-point" sql-type="FLOAT8" java-type="Double"><validate method="isSignedDouble"/></field-type-def>

        So these "floating-point" types translate to java Doubles when hydrated from the database. If you look at "InventoryItem" for example, its field definition is <field name="quantityOnHandTotal" type="fixed-point"></field> (for QOH).

        Show
        Bob Morley added a comment - Right and in the fieldtypepostgres.xml ... <field-type-def type="fixed-point" sql-type="NUMERIC(18,6)" java-type="java.math.BigDecimal"><validate method="isSignedDouble"/></field-type-def> <field-type-def type="floating-point" sql-type="FLOAT8" java-type="Double"><validate method="isSignedDouble"/></field-type-def> So these "floating-point" types translate to java Doubles when hydrated from the database. If you look at "InventoryItem" for example, its field definition is <field name="quantityOnHandTotal" type="fixed-point"></field> (for QOH).
        Hide
        Adrian Crum added a comment -

        The java-type elements in the fieldtype files specify the object type the JDBC driver is expecting. In other words, the Postgres JDBC driver expects a Double for SQL type FLOAT8. So, that can't be changed without some potential compatibility issues.

        On the other hand, the service definitions can specify any Java object type you want.

        Show
        Adrian Crum added a comment - The java-type elements in the fieldtype files specify the object type the JDBC driver is expecting. In other words, the Postgres JDBC driver expects a Double for SQL type FLOAT8. So, that can't be changed without some potential compatibility issues. On the other hand, the service definitions can specify any Java object type you want.
        Hide
        Bob Morley added a comment -

        Sure, but this is not suggesting that at all. It is suggesting that when the entities were changed to use a BigDecimal instead of a Double for storage (work that Scott had completed I believe) and this set of entities appear to be missed. The suggesting is changing the entity model from "floating-point" to "fixed-point" in the exact same manner as what was done with the other entities that went through this conversion.

        The trouble with the service definition approach is that for general CRUD type services the definition is usually defined using an "auto-attributes" element. So what we run into now is a call to "createProductionRun" requires a quantity as a BigDecimal (as per its entity model). The implementation takes that context and uses it to call "createWorkEffort" that requires a quantity as a Double ... and poof

        The solution here was to either say "Double" is right for WorkEffort and the service implementation needs to convert from BgiDecimal -> Double before calling runSync OR the entity model is incorrect and we should convert it to "BigDecimal". The latter is the one that Scott indicated was probably the correct solution.

        Show
        Bob Morley added a comment - Sure, but this is not suggesting that at all. It is suggesting that when the entities were changed to use a BigDecimal instead of a Double for storage (work that Scott had completed I believe) and this set of entities appear to be missed. The suggesting is changing the entity model from "floating-point" to "fixed-point" in the exact same manner as what was done with the other entities that went through this conversion. The trouble with the service definition approach is that for general CRUD type services the definition is usually defined using an "auto-attributes" element. So what we run into now is a call to "createProductionRun" requires a quantity as a BigDecimal (as per its entity model). The implementation takes that context and uses it to call "createWorkEffort" that requires a quantity as a Double ... and poof The solution here was to either say "Double" is right for WorkEffort and the service implementation needs to convert from BgiDecimal -> Double before calling runSync OR the entity model is incorrect and we should convert it to "BigDecimal". The latter is the one that Scott indicated was probably the correct solution.
        Hide
        Adrian Crum added a comment -

        Okay, so the field types need to be changed from floating-point to fixed point. Are there any other changes needed in the Work Effort component that you are aware of?

        Show
        Adrian Crum added a comment - Okay, so the field types need to be changed from floating-point to fixed point. Are there any other changes needed in the Work Effort component that you are aware of?
        Hide
        Bob Morley added a comment -

        Not sure if you mean "Work Effort component" or "Work Effort entity" ? For the latter the answer is no; the former is a pretty loaded question. To be honest, we have just started to really get into the manufacturing / work effort areas of the application so my knowledge of that space is pretty skimpy. BJ has been very valuable shedding some light on how stock Ofbiz works.

        The only thing that seems odd to me is the handling of tasks in the PR as it relates to "WorkEffortPartyAssignment". I see how these are copied from the routing task when they are adding the PR, but it does not appear that you can update the party who will be doing that work after the task has been added. Moreover, in the Work Effort component these tasks do not appear at all (without looking, it appears that the PR header / routing tasks are excluded form the WE find). If you know anything off the top of your head about that it would be much appreciated; otherwise I am going to continue my reading.

        Show
        Bob Morley added a comment - Not sure if you mean "Work Effort component" or "Work Effort entity" ? For the latter the answer is no; the former is a pretty loaded question. To be honest, we have just started to really get into the manufacturing / work effort areas of the application so my knowledge of that space is pretty skimpy. BJ has been very valuable shedding some light on how stock Ofbiz works. The only thing that seems odd to me is the handling of tasks in the PR as it relates to "WorkEffortPartyAssignment". I see how these are copied from the routing task when they are adding the PR, but it does not appear that you can update the party who will be doing that work after the task has been added. Moreover, in the Work Effort component these tasks do not appear at all (without looking, it appears that the PR header / routing tasks are excluded form the WE find). If you know anything off the top of your head about that it would be much appreciated; otherwise I am going to continue my reading.
        Hide
        Adrian Crum added a comment -

        Bob,

        Thank you for the information. I will work on this issue this weekend if no one beats me to it.

        I am about to deploy Manufacturing where I work, so I'm learning it as well. Maybe between the two of us we can get some documentation on the Wiki and work out any kinks we encounter.

        Show
        Adrian Crum added a comment - Bob, Thank you for the information. I will work on this issue this weekend if no one beats me to it. I am about to deploy Manufacturing where I work, so I'm learning it as well. Maybe between the two of us we can get some documentation on the Wiki and work out any kinks we encounter.
        Hide
        Bob Morley added a comment -

        Adrian – I am working through a production run and ran into a slight glitch related to this. The ProductionRun class has a quantity on it defined as a BigDecimal. In the store() method on this class, it uses this to set the value on the WorkEffortGoodStandard. In our source, this entities "estimatedQuantity" field is a java double which causes a big fat stack trace (but does do the conversion). My hope is you will include WorkEffortGoodStandard in your conversion efforts.

        Also – take a look at getProductProduced which figures out how many products will be produced for this production run (by getting the WorkEffortGoodStandard product to be delivered). This qty is originally set in createProductionRun by the production run's desired quantity. However, when store() is called it does not update the qty on the ProductionRun – just the underlying WorkEffortGoodStandard value. It seems to me we should consider having it update the ProductionRun's work effort "quantityToProduce" as well.

        Show
        Bob Morley added a comment - Adrian – I am working through a production run and ran into a slight glitch related to this. The ProductionRun class has a quantity on it defined as a BigDecimal. In the store() method on this class, it uses this to set the value on the WorkEffortGoodStandard. In our source, this entities "estimatedQuantity" field is a java double which causes a big fat stack trace (but does do the conversion). My hope is you will include WorkEffortGoodStandard in your conversion efforts. Also – take a look at getProductProduced which figures out how many products will be produced for this production run (by getting the WorkEffortGoodStandard product to be delivered). This qty is originally set in createProductionRun by the production run's desired quantity. However, when store() is called it does not update the qty on the ProductionRun – just the underlying WorkEffortGoodStandard value. It seems to me we should consider having it update the ProductionRun's work effort "quantityToProduce" as well.

          People

          • Assignee:
            Unassigned
            Reporter:
            Bob Morley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development