openerp-community team mailing list archive

[David Arnold - El Alemán <david@xxxxxxxxxxx>]

*Comments in bold white*
*Maybe someone from the publisher can drop his 2 cents as well.*


2014-06-25 10:11 GMT-05:00 Gustavo Adrian Marino <gamarino@xxxxxxxxx>:

> David:
> If I understood well, you have a problem with 'in' and 'not in' operators
> in orm search.
>
​*Correct.*​

>
> In general, the ORM translate directly both operations into the
> corresponding SQL Where clause. Nevertheless the logic does not work well
> with one2many or many2many relations. In particular, it does not support
> for example a test for collection = [].
>
*The common pattern of 2m fields is that the right side of the leaf  might
contain the higher cardinality between left and right side (as opposite to
m2 relations). This might produce the case where one want's to check, if in
a left-op-right leaf the left side is an entire subset of the right side
(read english: left "in" right). This however is not the functionality of
the (read openerp) "in" operator wich would be (read english) "entirely
contains" (thus right being an entire subset of left / or equal).*
*example: left = [1,2,3,4],  openerp "in", right = [2,3]      returns true
:(*

>
> If this is the issue, I could recomend yout to try with the patches
> published in the following bug, with patches  valid for 7.0 (and I guess is
> the same for 8.0):
> https://bugs.launchpad.net/openobject-server/+bug/1263401
>
​*Reading your bug rational**, it seems however, this might be a different
case. It seems that it is rather the character of a real bug, that you
describe.*

 *The case we are facing, is that a standard logical operator (read
enlgish) left "in" right is just missing. It's not there. It seems to me an
awakward thing for a framework that already exists some time, and claims a
battle tested core...*
*One very very ugly solution is to use the following transformation *[image:
A \subseteq B \Rightarrow A^{\rm c} \supseteq B^{\rm c}] *constructing the
complements of each side. On the left side via a function field (which
needs to update all stored complements, every time a new available 2m id is
added) and on the right side via a logical operation on runtime. THIS IS
AWFUL, however... The other solution would be, to hack the core. Proably a
"Frühlingsputz" would be a good initative.*

*Meanwhile we might to be forced to hack the expressions.py as well. Here
is the question about that: how should we deal with the denomination
"error" (see read english/read odoo above). We could just introduce an
operator (read openerp) "contains" with its negate wich translates in plain
english to "in". However, I'm not sure, if it is a good idea to perpetuate
an error. (disclaimer: I'f I'm not missing something...)*

 *Translating your issue in the subset of plain enlish I used to describe
the issue would translate to:*
*The right side of the leaf is an empty list*
*The left side of the leaf is an 2m-field.*
*The operator is "=" and doesn't return it's logical truthiness value
correctly in the case of an empty list on the right side of the leaf.*



> Best regards
>
​​*Thank you very much, I utterly appreaciated your concise answer.
Although I would prefer no bugs, I apreciate very much that we can discuss
such fundamentals here. *

>
> Gustavo Adrian Marino
>
> Mobile: +54 911 5498 2515
>
> Email: gamarino@xxxxxxxxx
>
> Skype: gustavo.adrian.marino
>
>
>
>
>
>
> 2014-06-25 0:58 GMT-03:00 David Arnold - El Alemán <david@xxxxxxxxxxx>:
>
>>  *Hi*
>>
>> *This might be somewhat too advanced for the odoo help. So I hope to find
>> some cracks here...*
>>
>>  We have noticed that the domain operator "in" the (left, operand, rigth)
>> leaf is defined as "[image: \supset]".
>> Which at least in german translates to "containes" (the complement of
>> "in") This is somehow syntactically (plain english) awkward. Maybe there is
>> a good reason for it...
>>
>> However, there is no operator for a true "in" or "[image: \subset]
>> " available.
>>
>> Note that,
>>
>> [image: A \subseteq B \Rightarrow A^{\rm c} \supseteq B^{\rm c}] (so
>> obivous, that "not in" is not the right solution)
>>
>> Maybe a way could be to apply this transformation:
>>
>> [image: A \subseteq B \Leftrightarrow A \cap B = A]
>>
>> where A would be the field_value (which is passed at runtime of rule
>> application only and therefore unchangable beforehand), but we probably can
>> make an operation such as the intersection of A & B ... F*** this doesn't
>> work either, as the A's are a hell lot of table records, which in turn are
>> not available at the time of construction of the rule)
>>
>> *Any ideas? Am I missing something... This is very sad news, as
>> everything else on the famos tax application seems to work :((((*
>>
>> *Thank you!*
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>