[
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:41 AM:
--------------------------------------------------------------
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.*
was (Author: diveshdut):
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.
