[Openerp-community] advanced logical domain oeration

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Openerp-community] advanced logical domain oeration

David Arnold - El Alemán
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 "\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 "\subset" available.

Note that,

 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:

 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] advanced logical domain oeration

Gustavo Adrian Marino
David:
If I understood well, you have a problem with 'in' and 'not in' operators in orm search.

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 = [].

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

Best regards

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-25 0:58 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
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 "\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 "\subset" available.

Note that,

 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:

 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] advanced logical domain oeration

David Arnold - El Alemán
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 <[hidden email]>:
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  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: <a href="tel:%2B54%20911%205498%202515" value="+5491154982515" target="_blank">+54 911 5498 2515

Email: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-25 0:58 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
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 "\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 "\subset" available.

Note that,

 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:

 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp




_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] advanced logical domain oeration

Gustavo Adrian Marino
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: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-25 13:03 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
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 <[hidden email]>:

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  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: <a href="tel:%2B54%20911%205498%202515" value="+5491154982515" target="_blank">+54 911 5498 2515

Email: [hidden email]

Skype: gustavo.adrian.marino

 

 



2014-06-25 0:58 GMT-03:00 David Arnold - El Alemán <[hidden email]>:
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 "\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 "\subset" available.

Note that,

 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:

 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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] advanced logical domain oeration

David Arnold - El Alemán
Gustavo, first of all, thank you a LOT for your brainshare.
  • 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. 
​Thanks for this acclaration I ignored the "as long as one" part so far. This means that the openerp "in"​ has nothing to do with subsets in neither direction. This automatically means, the proposed workaround with the complement - apart from being ugly - would not have worked.
  • ​​
    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
    ​.
​Correct.​
​This is exactly the situation. I'm now analyzing also another link for performance considerations: http://stackoverflow.com/questions/7364969/how-to-filter-sql-results-in-a-has-many-through-relation
  • 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
​That's the way to go. should be 'not is contained' to run smoothly through the operator[4:] statements...​ I think such a code could easily cover 4 cases, left is contained in right, right is contained in left and their corresponding negations. negations probably isn't neceseary as we have the '!' operator on tuples... well code will show how to do it best.

Thank you for your guidance!

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp