On 09/17/2013 04:44 PM, Alexandre Fayolle - camptocamp wrote:
> unfortunately, the bug is still there: on runbot, with the current
> setup, if I type "aa" in the creation step of a Sale Order, I see AAA10
> but not "Best Designers, Ayaan Agarwal", which suddenly pops up if I
> type an additional "n".
Yes, that's why I explicitly mentioned that the patch does not solve the bug.
If anything, it actually makes the bug more consistently reproducible, while it
used to be semi-random.
However the suggested patch is ugly and complex, and the person writing it
should be sure to understand the performance implication of any alteration of
the current code.
As a possible workaround, I've pushed an experimental fix in branch lp:~openerp-dev/openobject-addons/7.0-bug-1203727-hack. It might sufficiently
decrease the chance of triggering the bug, without incurring a noticeable
performance hit on most databases, and without the complexity of the full
patch. It is still possible to trigger the bug with pathological cases, so
testing it on real customer databases should tell us if it is an acceptable
workaround for v7.0.
v8 will feature a complete fix, but this requires a change in the ORM system
that is not suitable for 7.0 stable.
On 09/17/2013 04:44 PM, Alexandre Fayolle - camptocamp wrote:
> unfortunately, the bug is still there: on runbot, with the current
> setup, if I type "aa" in the creation step of a Sale Order, I see AAA10
> but not "Best Designers, Ayaan Agarwal", which suddenly pops up if I
> type an additional "n".
Yes, that's why I explicitly mentioned that the patch does not solve the bug.
If anything, it actually makes the bug more consistently reproducible, while it
used to be semi-random.
I've highlighted some possible solutions to the fundamental problem in comment /code.launchpad .net/~tsabi/ openobject- server/ 7.0-tsabi- res_partner_ name_search_ limit_fix/ +merge/ 176050
#3 of MP
https:/
However the suggested patch is ugly and complex, and the person writing it
should be sure to understand the performance implication of any alteration of
the current code.
As a possible workaround, I've pushed an experimental fix in branch
lp:~openerp-dev/openobject-addons/7.0-bug-1203727-hack. It might sufficiently
decrease the chance of triggering the bug, without incurring a noticeable
performance hit on most databases, and without the complexity of the full
patch. It is still possible to trigger the bug with pathological cases, so
testing it on real customer databases should tell us if it is an acceptable
workaround for v7.0.
v8 will feature a complete fix, but this requires a change in the ORM system
that is not suitable for 7.0 stable.