c2c-oerpscenario team mailing list archive

[Raphaël Valyi - http://www.akretion.com <709567@xxxxxxxxxxxxxxxxxx>]

@Naresh,

Thank you for investigating, I believe the analysis of Olivier is exact
about the read in osv_mem.
about your comment "The screenshot that you provided in comment #2
@lp:709559 . The wizard will only show you the moves that are still left to
be processed."
-> the difference of stock move numbers in the popup really comes from an
OpenERP bug (aknowledged now) because of some hard limit in the number of
osv_memory records OpenERP sessions can hold currently. But this was a
different issue and is dealt in a separated bug report.

On Tue, Feb 1, 2011 at 6:59 AM, Naresh(OpenERP) <nch@xxxxxxxxxxx> wrote:

> Hello,
>
> Regarding the 'name_get' call:
>
> The architecture that the GTK as well as web follows is that for each
> O2M (here product_moves) it will perform a read now say it returned a
> list of dictionary([{}]) of 9 records eg: [{'product_id': 3,
> 'product_uom': 1, '__last_update': False, 'prodlot_id': False, 'id': 50,
> 'quantity': 1.0}, {'product_id': 9, 'product_uom': 1, '__last_update':
> False, 'prodlot_id': False, 'id': 51, 'quantity': 1.0}, {'product_id':
> 16, 'product_uom': 1, '__last_update': False, 'prodlot_id': False, 'id':
> 52, 'quantity': 1.0}, {'product_id': 13, 'product_uom': 1,
> '__last_update': False, 'prodlot_id': False, 'id': 53, 'quantity': 1.0},
> {'product_id': 12, 'product_uom': 1, '__last_update': False,
> 'prodlot_id': False, 'id': 54, 'quantity': 1.0}, {'product_id': 11,
> 'product_uom': 1, '__last_update': False, 'prodlot_id': False, 'id': 55,
> 'quantity': 1.0}, {'product_id': 14, 'product_uom': 1, '__last_update':
> False, 'prodlot_id': False, 'id': 56, 'quantity': 1.0}, {'product_id':
> 21, 'product_uom': 1, '__last_update': False, 'prodlot_id': False, 'id':
> 57, 'quantity': 1.0}, {'product_id': 3, 'product_uom': 1,
> '__last_update': False, 'prodlot_id': False, 'id': 58, 'quantity': 3.0}]
>
> Now the GTK and web will iterate over this list and then internally by
> field so based on the type of the field it will create the instance of
> that type of field say for eg:here we take 'product_id' now it will make
> a call to 'name_get' get its name and fill the many2one field. similarly
> for the rest  of the records.
>
> The same architecture is implemented in GTK and web.
>
> @Raphaël Valyi
>  The screenshot that you provided in comment #2 @lp:709559 . The wizard
> will only show you the moves that are still left to be processed.
>
> Thanks
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/709567
>
> Title:
>  [6.0.1][stock] large picking slow performance
>
> Status in OpenERP GTK Client:
>  Confirmed
>
> Bug description:
>  Hello,
>
>  I've a production case with 315 moves in a picking, when clicking on
>  process, the wizard last for nearly a minute to appear depending on
>  your network latency because it makes a name_get RPC call for each
>  line instead of reading it by batch, see the following GTK RPC logs +
>  full description here (I open a new bug as those are separated
>  concerns): https://bugs.launchpad.net/openobject-addons/+bug/709559
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openobject-client/+bug/709567/+subscribe
>

-- 
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/709567

Title:
  [6.0.1] many2one fields should be read as (id, name) also for
  osv_memory objects (saving name_get RPC calls)

Status in OpenERP Server:
  In Progress

Bug description:
  Hello,

  I've a production case with 315 moves in a picking, when clicking on
  process, the wizard last for nearly a minute to appear depending on
  your network latency because it makes a name_get RPC call for each
  line instead of reading it by batch, see the following GTK RPC logs +
  full description here (I open a new bug as those are separated
  concerns): https://bugs.launchpad.net/openobject-addons/+bug/709559