[10.0] partner multi relation extendable

[NL66278]

Make it easy and reliable to show all kinds of relations between partners. Not only those entered manually, but also between partners and their contact persons/addresses. Of betwee customers and their sales persons.
The changes to this module provide the flexibility on which extension modules can build.

[hbrunn]

consider using git commit --fixup=$hash_of_previous_commit. Because then, you don't need to fill in a commit message and, rebasing is simply git rebase -i $hash_of_previous_commit~1 --autosquash

[rousseldenis]

@NL66278 As partner_multi_relation is on 10.0 branch, could you rebase all your PR's concerning that module ?

We could see more clearly what changes are involved in them and move forward.

Thanks

[ghost]

@NL66278 Thank you, LGTM 👍

[NL66278]

@hbrunn @rousseldenis @dufresnedavid Now that this PR is used for the migration to 11.0 it might be time to merge it in 10.0? Not only is this change the base for extention modules, but some annoying buds have been solved and tests have been extended.

[ddufresne]

Yes, let's merge this pull request.

[NL66278]

@ddufresne For a merge we need two approvals. Please go to the changes tab and use the button 'Review Changes'

[hbrunn]

I still disagree with this whole construction, please read http://effbot.org/zone/thread-synchronization.htm if you won't take it from me.

Why can't you do something similar as in https://github.com/OCA/OCB/blob/10.0/addons/account/report/account_invoice_report.py#L94? this then also is very much in line with the way Odoo inheritance works

[NL66278]

@hbrunn What happens in account_invoice_report is not really applicable, because there they have a single monolitic SQL statement, where inheriting modules can add something to the where or the from or the whatever. In my case all relations are a UNION of SQL statements (ofcourse together they are one statement), that each can have their own joins, wheres, whatevers, if only in the end the select the right number of columns of the right type. And ofcourse they should be a link from one partner to another. Apart from the modules already realized you could link managers to employees, salesmen to customers, any relation between partners you think are interesting to show as a connection.

As for the dangers of multithreading in combination with global variables I need no convincing. But as far as I can see module loading is not a multithreaded proces. Otherwise really wierd things could happen when for instance the ordering of model inheritance would become completely inpredictable.

Actually module loading itself uses some global variables. Like the quite important loaded array in modules/module.py, containing the modules already loaded. How does this differ from what I do?

[hbrunn]

by virtue of https://github.com/OCA/OCB/blob/10.0/odoo/modules/registry.py#L68

But let's not argue this point too much, I shouldn't have started with this most interesting argument, but the most compelling one: Global variables holding state will blow up when you have multiple databases in a threaded server. Consider what happens when db1 has two modules doing this, while db2 has one. Or none, doesn't matter. Don't you remember the times when people used globals all over the place and things went south constantly?

My example was just that, an example. For your case, I guess I'd do something like

def _get_statements(self):
    return ['select * from table']

def _get_statement(self):
    cr.execute(' union '.join(self._get_statements))

or something similar. Overrides then append to the list. Given you have probably quite some code using this already, _get_statements could just return a list of the dicts you're using anyways, then you don't have to change much code but still are thread safe.

[NL66278]

@hbrunn I hope you can be satisfied with the changes in the PR.

[hbrunn]

some elaborate comment in the function docstring how people are supposed to override would be nice, but that can come later too. thanks. I count this message as approval so we can merge.