← Back to team overview

c2c-oerpscenario team mailing list archive

Re: [Bug 715749] Re: [trunk] [5.0] [6.0] keep ids order on read method with an _inherits object

 

Hello Olivier and others,

so if that cost performance (which I understand), why not make this some
optional flag on the read method. So when you need it you have, but only
when you really need it?
At some point I don't find it normal everyone would have to re-implement
their own hacked sorted read in their custom module as we did in
base_external_referentials nor would I find it normal to suddenly add a perf
penalty to all read call while 99% of them don't need an ordered result.
Thoughts?


On Tue, Mar 15, 2011 at 11:13 AM, Olivier Dony (OpenERP) <
715749@xxxxxxxxxxxxxxxxxx> wrote:

> Just for the record, this is the comment I added on Quentin's merge
> proposals against 5.0 and 6.0, where he added in-memory sorting of
> read's result:
>
> ~~~
> Quentin, thank you for the merge proposal, however we cannot accept such a
> change in stable branches, like 5.0 or 6.0.
> You may want to re-submit against the trunk version only.
>
> But even for trunk, this in-memory sorting of the results of read() can be
> a performance problem, and this is the reason why read() does not re-sort
> the result when it returns them.
> Read() is basically a "SELECT [fields] from table where id in [ids]" which
> postgres has no reason to sort in the order of [ids]. To be able to do that,
> read() should receive the sort order to use, and thus pass it in the SELECT
> query.
>
> This requires an API change, and in order to avoid duplicating the
> features of search() there, it would probably make sense to implement
> this as part of a new combined search_read() method, that would do both
> things at the same time, using postgres to implement the ordering
> efficiently.
>
> Hope this helps.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Server.
> https://bugs.launchpad.net/bugs/715749
>
> Title:
>  [trunk] [5.0] [6.0] keep ids order on read method with an _inherits
>  object
>
> Status in OpenERP Server:
>   Confirmed
>
> Bug description:
>  On v.5 and v.6 trunk.
>
>  When you give a list of ids on read function of an _inherits object
>  (like product.product), the read function returns automatically a list
>  of dictionnaries sorted by id (for product.product) even if you give a
>  not sorted list of id.
>
>  To see that, on a new db with demo data, create a XML-RPC script which
>  search all products with 'pc' in their name. This search function
>  returns you a list of ids sorted by id. Take this list of ids and
>  sorted it again with the biggest id at first and the smallest at last.
>
>  Give this new sorted list to the read function and see the result of
>  this function : the list of result is sorted by id (with the smallest
>  id at first).
>
>  It's a bug because the read function doesn't keep the order of ids
>  give to the function.
>

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

Title:
  [trunk] [5.0] [6.0] keep ids order on read method with an _inherits
  object

Status in OpenERP Server:
  Confirmed

Bug description:
  On v.5 and v.6 trunk.

  When you give a list of ids on read function of an _inherits object
  (like product.product), the read function returns automatically a list
  of dictionnaries sorted by id (for product.product) even if you give a
  not sorted list of id.

  To see that, on a new db with demo data, create a XML-RPC script which
  search all products with 'pc' in their name. This search function
  returns you a list of ids sorted by id. Take this list of ids and
  sorted it again with the biggest id at first and the smallest at last.

  Give this new sorted list to the read function and see the result of
  this function : the list of result is sorted by id (with the smallest
  id at first).

  It's a bug because the read function doesn't keep the order of ids
  give to the function.



References