c2c-oerpscenario team mailing list archive

[xrg <xrg@xxxxxxxxx>]

On Wednesday 04 May 2011, you wrote:
> Public bug reported:
> 
> Hello,
> 
> This is specially useless given hat by default, the stock.location tree
> view has the real_stock and virtual_stock fields but they ARE HIDDEN!!!
> Indeed:
>    <field name="stock_real" invisible="'product_id' not in context"/> 

> My understanding is that those stock level fields are only useful when you
> use the "stock by location" right side link from a product form. In the
> regular stock location tree view they are just useless.
> 
> So a simple fix that dramatically speeds up the display of the stock
> location tree view, is to go in the stock_location#_product_value method
> and simply returns False early when no product_id is provided.
> 
> See the attached patch.
> 
> I'm not 100% sure there is no side effect of doing that.

Well, your patch is obviously a good workaround.

But my question is: why does the client (Gtk one or web?) ask for values for 
invisible fields in the first place [1]?
IMHO (unless somebody has a better argument) that invisible fields should /not/ 
participate in the "fields" kwarg of read() . If so, your patch, Raphael, would 
be redundant.


[1] there are many expensive function fields all over the place. Minimizing the 
fields queried in read() will help in the long run.

-- 
Say NO to spam and viruses. Stop using Microsoft Windows!

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/777121

Title:
  [6.0.2][stock] stock location list is slow because it always compute
  stock levels even if field is hidden; patch included

Status in OpenERP Modules (addons):
  New

Bug description:
  Hello,

  we have a few customers with many stock moves. One with over 300 000
  moves. Displaying the list of stock locations can take like more than
  1 minutes on their installations. The worst use case is when they are
  manually changing some stock location of some move or for an
  inventory, the name search will possibly result in showing the list of
  location and computing the real and virtual stock levels of all those
  locations. Of course, the more moves you have, the slower that stock
  level computation goes...

  This is specially useless given hat by default, the stock.location
  tree view has the real_stock and virtual_stock fields but they ARE
  HIDDEN!!! Indeed:

  <tree string="Stock Location" colors="blue:usage=='view';darkred:usage=='internal'">
                      <field name="complete_name"/>
                      <field name="usage"/>
                      <field name="stock_real" invisible="'product_id' not in context"/>
                      <field name="stock_virtual" invisible="'product_id' not in context"/>
                  </tree>

  
  My understanding is that those stock level fields are only useful when you use the "stock by location" right side link from a product form. In the regular stock location tree view they are just useless.

  So a simple fix that dramatically speeds up the display of the stock
  location tree view, is to go in the stock_location#_product_value
  method and simply returns False early when no product_id is provided.

  See the attached patch.

  I'm not 100% sure there is no side effect of doing that. But the patch is a life saver in the cases I have.
  If there are sides effects (you should absolutely investigate it, specially the stock valuation things), then I think one must think into providing a specific tree view without those stock value fields for the regular stock location list and the one that pops up in the stock moves for the source and destination location. An other way would be to specify in the context when those fields are really required or not if product_id is not a valid discriminant.

  Hope this helps. I believe it also affect 5.0 and trunk as well.