Regards Scott
HotWax Media http://www.hotwaxmedia.com On 1/05/2009, at 6:17 PM, Jacques Le Roux wrote:
I personnaly prefer that we keep it (anyway this would be a Jira demand to infra) because sometimes it's useful. But totally agree that we should use this feature parsimoniously The problem with this kind of non authoritative approach is that you have to explain over and over. On the other hand, this is what we call education...Jacques From: "Scott Gray" <[email protected]>Hi Divesh (and anybody else who does this regularly)Wherever possible please avoid editing comments (I almost wish we could turn it off), most of us read jira issues through email notifications and it is impossible to know what you've changed in your comment.Thanks Scott HotWax Media http://www.hotwaxmedia.com On 1/05/2009, at 4:36 PM, Divesh Dutta (JIRA) wrote:[ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704689 #action_12704689 ]Divesh Dutta edited comment on OFBIZ-2388 at 4/30/09 9:35 PM: -------------------------------------------------------------- Hello David, Please see my comments inline :The way this is implemented will not scale adequately for deployments with large numbers of orders.In the ReviewOrdersNotPickedOrPacked.groovy file the first line of code gets ALL OrderHeader records from the database, ie:orderHeaders = delegator.findList("OrderHeader", null, null, null, null, false);This is not acceptable as there could be hundreds of thousands of millions of orders in the database, and so this line will fail.*Very true. Here we can add condition. Below is the code snippet. Please suggest.* {quote}condList.add(EntityCondition.makeCondition("statusId", EntityOperator.EQUALS, "ORDER_APPROVED")); condList.add(EntityCondition.makeCondition("orderTypeId", EntityOperator.EQUALS, "SALES_ORDER")); condList .add(EntityCondition.makeCondition("pickSheetPrintedDate", EntityOperator.NOT_EQUAL, null));cond = EntityCondition.makeCondition(condList, EntityOperator.AND);orderHeaderList = delegator.findList("OrderHeader", cond, null, null, null, false);{quote}Later on down in the file the code looks for Shipment records with a primaryOrderId that matches the orderId on each OrderHeader, and then looks at other things on the Shipment record(s) corresponding.All of this can, and should, be done with a view entity. In fact, it must be done with a view entity so that the work is done in a query in the database and not in a script on the app server which is hugely inefficient, so much so that in even moderately large systems it simply WILL NOT WORK!*Agreed*An addition note: looking for shipments by matching the OrderHeader.orderId with the Shipment.primaryOrderId is not adequate. Please change it to match the OrderHeader.orderId with the ItemIssuance.orderId and then ItemIssuance.shipmentId with Shipment.shipmentId. Not that there will be many records for a single OrderHeader and Shipment combination since the ItemIssuance really ties a OrderItem to a ShipmentItem, but that is fine since in this case all we care about is the OrderHeader to Shipment relationship. Why do we need this? Because it is possible for a single Shipment to have items from different orders on it, and simply looking at the Shipment.primaryOrderId won't capture that... that field is only the PRIMARY orderId.*But here the confusion is , Entries in ItemIssuance Entity is not done when we do "Verify Pick" (only done when shipment is created in Packed status). So Entries are not present in ItemIssuance entity for Orders which have shipment in "Input", "Picked", and "Scheduled" status. So IMO above given logic will not help . Please let me know if I am wrong.*was (Author: diveshdut): Hello David, Please see my comments inline :The way this is implemented will not scale adequately for deployments with large numbers of orders.In the ReviewOrdersNotPickedOrPacked.groovy file the first line of code gets ALL OrderHeader records from the database, ie:orderHeaders = delegator.findList("OrderHeader", null, null, null, null, false);This is not acceptable as there could be hundreds of thousands of millions of orders in the database, and so this line will fail.*Very true*Later on down in the file the code looks for Shipment records with a primaryOrderId that matches the orderId on each OrderHeader, and then looks at other things on the Shipment record(s) corresponding.All of this can, and should, be done with a view entity. In fact, it must be done with a view entity so that the work is done in a query in the database and not in a script on the app server which is hugely inefficient, so much so that in even moderately large systems it simply WILL NOT WORK!*Agreed*An addition note: looking for shipments by matching the OrderHeader.orderId with the Shipment.primaryOrderId is not adequate. Please change it to match the OrderHeader.orderId with the ItemIssuance.orderId and then ItemIssuance.shipmentId with Shipment.shipmentId. Not that there will be many records for a single OrderHeader and Shipment combination since the ItemIssuance really ties a OrderItem to a ShipmentItem, but that is fine since in this case all we care about is the OrderHeader to Shipment relationship. Why do we need this? Because it is possible for a single Shipment to have items from different orders on it, and simply looking at the Shipment.primaryOrderId won't capture that... that field is only the PRIMARY orderId.*But here the confusion is , Entries in ItemIssuance Entity is not done when we do "Verify Pick" (only done when shipment is created in Packed status). So Entries are not present in ItemIssuance entity for Orders which have shipment in "Input", "Picked", and "Scheduled" status. So IMO above given logic will not help . Please let me know if I am wrong.*Add a page that shows orders with the "pick sheet printed date" field--------------------------------------------------------------------- Key: OFBIZ-2388 URL: https://issues.apache.org/jira/browse/OFBIZ-2388 Project: OFBiz Issue Type: Sub-task Components: product Affects Versions: SVN trunk Reporter: Pranay Pandey Assignee: Vikas Mayur Fix For: SVN trunk Attachments: ofbiz-2388.patch* Add page that shows orders with the "pick sheet printed date" field set that do not have a Shipment associated with them that is in the "Input" or "Scheduled" statuses (should be in Input status, but just in case Scheduled is eventually used), sorted by the oldest date first to see the ones that have gone the longest without being picked and verified.* Link to new page from the PicklistOptions page.-- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
smime.p7s
Description: S/MIME cryptographic signature
