openerp-india team mailing list archive

[Kyle Waid <1077991@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Stock is calculated based on stock moves. Each time I click on a product
view, perform a manufacturing operation, etc the system will calculates
the products current stock value. It will always compute the stock from
the first stock move to the last one. There is no concept of a stock
period. The resulting affect is an un-scalable system. With only a few
products, stock locations, uom and limited use the system will perform
sufficiently. If you intend to use the software for larger deployments,
eventually the stock move table will have so many records that stock
computation slows the system to a grinding halt.

Example is a current production system I am managing has over 3 million
stock moves. Stock computation can take up to 30 seconds because it
selects all records and computes the stock from the beginning of time.
In this model, the system will not scale, and be unusable for any user
after a period of time.

In addition to this problem the method that computes a products stock is poorly written.
http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/stock/stock.py
Starting line 101

Why on earth would you first select DISTINCT from the database, then
sort data in python. To me this makes no sense, and is a very costly
operation. IMO This method should be completely re-written

** Affects: openobject-addons
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/1077991

Title:
  Stock computation and storage inefficient and not scalable

Status in OpenERP Addons (modules):
  New

Bug description:
  Stock is calculated based on stock moves. Each time I click on a
  product view, perform a manufacturing operation, etc the system will
  calculates the products current stock value. It will always compute
  the stock from the first stock move to the last one. There is no
  concept of a stock period. The resulting affect is an un-scalable
  system. With only a few products, stock locations, uom and limited use
  the system will perform sufficiently. If you intend to use the
  software for larger deployments, eventually the stock move table will
  have so many records that stock computation slows the system to a
  grinding halt.

  Example is a current production system I am managing has over 3
  million stock moves. Stock computation can take up to 30 seconds
  because it selects all records and computes the stock from the
  beginning of time. In this model, the system will not scale, and be
  unusable for any user after a period of time.

  In addition to this problem the method that computes a products stock is poorly written.
  http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/stock/stock.py
  Starting line 101

  Why on earth would you first select DISTINCT from the database, then
  sort data in python. To me this makes no sense, and is a very costly
  operation. IMO This method should be completely re-written

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/1077991/+subscriptions