openerp-community team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

David:
I was thinking about your need. My comments:

   - In OpenERP a one2many or many2one set in a list is treated as True as
   long one of the elements of the field is contained in the list.
   It is widely used in security settings for multicompany objects, so
   changing the semantic is not advisable.
   - If I understood well, you look for a full containment of the field
   values into the list.
   Search expressions should convert your requirement to an SQL statement,
   so first you must have a clear view of the generated SQL.
   I've found the following example, I think it covers the requirement:
   http://stackoverflow.com/questions/8425232/sql-select-all-rows-where-subset-exists
   - I propose you to extend search clauses to include a 'is contained' or
   'is not contained" operator leading to an SQL sentence in the way is
   described on the previous link

Best regards

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino






2014-06-25 13:03 GMT-03:00 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
>>>
>>>
>>
>