Comment 7 for bug 715749

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) <
<email address hidden>> 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.
>