Community: Framework mailing list archives
Re: Relational Divisionby
Thank you Graeme!
I admit, the domain-operator idea might have derived from path dependency on the relational division topic, which is widely discussed in the context of RDBMS operations. It just seemed obvious to me, that this would have to be a DB operation. I'm not sure about the cost of both operations, but also in SQL I've seen quite efficient implementations. However following your hint, I realized the decent builtin set operations of Python as of 2.6. You can probably see, I'm neither a techie, nor a python supercharged funcional: I'm just a funcional with a problem to solve. ;)
I also like your suggestion to add this top level function to include a domain operator that dynamically handles it at ORM level, as it would keep my original code clean and avoide mixing design patterns.
The load of this function will be as follows: On every incoice line, a set of runtime parameters (derived from product, partner, copmany, shipping-partner, and maybe invoice.lline itself) will be matched against a rule table in the form that, if attributes of a given rule is a subset of runtime parameters, then apply rule. This rule then steers the application of taxes (on the invoice.line level) and accounts (on the invoice level). The rule table might be eventually large, however we could plan rule inheritence features in order to reduce the flat decision table probelm.
Anyone can comment on the performance issues we might incurr? I'm unable to assess this topic.
Investigating this topic further (and the well known dilemma of object relational impedance mismatch), I ask myself, if someone has thought about OODB implementation of odoo for some transaction heavier stuff. Just got curious.