[table].id IN (false) HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.

Bug #1124130 reported by Holger Brunn (Therp)
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Confirmed
Medium
OpenERP's Framework R&D
OpenERP Community Backports (Server)
Status tracked in 7.0
7.0
Fix Released
Medium
Holger Brunn (Therp)
Therp Backports (Deprecated)
Fix Released
Medium
Holger Brunn (Therp)
Server-6.1
Fix Released
Medium
Holger Brunn (Therp)

Bug Description

When getting many2one fields via the value= parameter which *name* is False, the error above is thrown.

This is caused by the fact that bool is an instance of int and http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/osv/fields.py#L465 filters out [x for x in res.values() if isinstance(x, (int,long))]

This applies to 6.1, 7.0, trunk, MPs follow

Related branches

Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

Horror:

bool(False - 1) == True

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Looks correct, thanks for the analysis and for the patch!

Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Note: please don't make identical merge proposals for trunk and the last stable unless trunk really needs a different kind of patch. The last stable branch can always be assumed to be periodically merged into trunk, and having both increases the administrative burden and the chance of creating conflicts.

Similarly, I'm not sure you should be making merge proposals for your various backport branches immediately after making them for the official branches: that sounds like increased noise, more administrative work, more chances of conflicts... perhaps only do that when you think the official MPs have been pending for too long? (not sure what makes the most sense, you decide)

Revision history for this message
Gustavo Adrian Marino (gamarino) wrote : Re: [Bug 1124130] Re: [table].id IN (false) HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.

The problem arises because the function receives 3 types of res
dictionaries:
- values with None/False
- simple ints
- tuples (id, name)
The attached patch handles the three cases correctly

2013/2/13 Olivier Dony (OpenERP) <email address hidden>

> Looks correct, thanks for the analysis and for the patch!
>
> ** Changed in: openobject-server
> Importance: Undecided => Medium
>
> ** Changed in: openobject-server
> Status: New => Confirmed
>
> ** Changed in: openobject-server
> Assignee: (unassigned) => OpenERP's Framework R&D
> (openerp-dev-framework)
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Server.
> https://bugs.launchpad.net/bugs/1124130
>
> Title:
> [table].id IN (false) HINT: No operator matches the given name and
> argument type(s). You might need to add explicit type casts.
>
> Status in OpenERP Server:
> Confirmed
>
> Bug description:
> When getting many2one fields via the value= parameter which *name* is
> False, the error above is thrown.
>
> This is caused by the fact that bool is an instance of int and
> http://bazaar.launchpad.net/~openerp/openobject-
> server/trunk/view/head:/openerp/osv/fields.py#L465 filters out [x for
> x in res.values() if isinstance(x, (int,long))]
>
> This applies to 6.1, 7.0, trunk, MPs follow
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/1124130/+subscriptions
>

--

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: <email address hidden>

Skype: gustavo.adrian.marino

Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

@olivier Are you kidding? I do not think that any of our fixes were ever applied to stable. We don't expect you to do so anymore. The OpenERP SA bug fixing policy also expresses that only high/critical issues will be taken into account. So when we say 'backport', it usually means 'apply to stable'. That warrants immediate backport branches of contributed fixes.

Changed in ocb-server:
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Holger Brunn (Therp) (hbrunn)
Changed in therp-backports:
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Holger Brunn (Therp) (hbrunn)
milestone: none → fixed-after-61
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

@Stefan: well I certainly don't blame you for doing the extra effort and I understand why you do it. It's just that I was planning to merge the fixes in the various stable branches and thought you were going to do the work twice or risked getting unnecessary conflicts.
BTW what we mean in the policy is that we will only backport patches ourselves for High+ issues. That does not preclude accepting MPs for past stable versions, especially if the issue is sufficiently serious (nothing that looks remotely like a wishlist) and if we receive a ready-to-merge MP from the community. No guarantees, but that means your MPs for 6.1 & 7.0 are useful :-) I'll adapt the wording on the bug management policy to make that more explicit.

Revision history for this message
Stefan Rijnhart (Opener) (stefan-opener) wrote :

That would be the best, thanks! Of course, if it turns out that backporting current fixes immediately is double work on which the official branches catch up quickly we will adapt the process. Conflicts should not occur because the change is represented by the same bzr revision id in all branches (using the clone script), although bzr seems to be pretty robust against identical code changes merged multiple times in distinct revisions too. Just don't add any extra spaces while merging ;-)

Changed in therp-backports:
status: Fix Committed → Fix Released
milestone: fixed-after-61 → 6.1-maintenance
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.