Thanks Scott,
I will surely keep this thing in mind. Thanks for your suggestion.
Divesh
Scott Gray wrote:
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.
