Convert WorkEffort (and related entities) quantities from Double -> BigDecimal
------------------------------------------------------------------------------ Key: OFBIZ-3700 URL: https://issues.apache.org/jira/browse/OFBIZ-3700 Project: OFBiz Issue Type: Bug Components: workeffort Affects Versions: SVN trunk Reporter: Bob Morley Priority: Minor Fix For: SVN trunk 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856921#action_12856921 ] Adrian Crum commented on OFBIZ-3700: ------------------------------------ Bob, What do you mean by converting the WorkEffort entity to BigDecimal? > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856924#action_12856924 ] Bob Morley commented on OFBIZ-3700: ----------------------------------- 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". :) > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856925#action_12856925 ] Adrian Crum commented on OFBIZ-3700: ------------------------------------ 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? > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856927#action_12856927 ] Bob Morley commented on OFBIZ-3700: ----------------------------------- 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). > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856931#action_12856931 ] Adrian Crum commented on OFBIZ-3700: ------------------------------------ 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. > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856939#action_12856939 ] Bob Morley commented on OFBIZ-3700: ----------------------------------- 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. > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856942#action_12856942 ] Adrian Crum commented on OFBIZ-3700: ------------------------------------ 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? > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856945#action_12856945 ] Bob Morley commented on OFBIZ-3700: ----------------------------------- 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. > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856948#action_12856948 ] Adrian Crum commented on OFBIZ-3700: ------------------------------------ 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. > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
(Replying outside of JIRA)
Adrian, Sounds good -- we are really just getting started with the manufacturing component / work effort component. The trouble I am running into (and this is pretty typical of working in any new ofbiz area) is understanding the data model coupled with the standard workflow. The UI tends to be CRUD based so it is difficult to figure out what things I should be providing with each step of a standard production run. The second problem is that we have last merged ofbiz about six months ago, and it appears a number of enhancements have gone into ProductionRunServices, so the behaviour I see in our solution is different from what I see on ofbiz-trunk demo. The things that are troubling my little brain now are ... - why is there no option to assign a party to a routing task in a PRun - it appears the changeProductionRunStatus and changeProductionRunTaskStatus do not enforce the StatusValidChange entity - we not only have "assembly" of products but also "disassembly"; not sure how I am going to do that ... logically it is just the inverse of an assembly, so I may consider "producing" multiple products of type RAW_MATERIAL from one or more FINISHED_GOODS - from data modeling v2 it appears that a services business may work with an "engagement" entity and/or a sub-class of order for "service order" ... ofbiz has neither of these, so I am unclear on how I am going to support straight service requests that have work effort involved On Apr 14, 2010, at 12:21 PM, Adrian Crum (JIRA) wrote: > > [ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856948 > #action_12856948 ] > > Adrian Crum commented on OFBIZ-3700: > ------------------------------------ > > 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. > |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum reassigned OFBIZ-3700: ---------------------------------- Assignee: Adrian Crum > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Assignee: Adrian Crum > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860752#action_12860752 ] Bob Morley commented on OFBIZ-3700: ----------------------------------- 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. > Convert WorkEffort (and related entities) quantities from Double -> BigDecimal > ------------------------------------------------------------------------------ > > Key: OFBIZ-3700 > URL: https://issues.apache.org/jira/browse/OFBIZ-3700 > Project: OFBiz > Issue Type: Bug > Components: workeffort > Affects Versions: SVN trunk > Reporter: Bob Morley > Assignee: Adrian Crum > Priority: Minor > Fix For: SVN trunk > > > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
Free forum by Nabble | Edit this page |