Tryton - Issues



Title ModelSingleton vs MultiValue
Priority feature Status chatting
Superseder Nosy List ced, oscar, pokoli, resteve
Type performance Components trytond
Assigned To Keywords

Created on 2017-12-01.15:23:39 by ced, last changed by oscar.

msg37436 (view) Author: [hidden] (oscar) (Tryton translator) Date: 2017-12-24.18:38:25

I solved all problems (migration, hard coding, debugging, maintenance, etc) removing both Multivalue and ModelSingleton, using just simple ModelSQL, how? Using a new configuration record for each company.

class MyModelConfiguration(ModelSQL, ModelView):
    company = fields.Many2One(.....) # required=True
    sequence_blabla = fields.Many2One('ir.sequence',....)
    parameter1 = fields.Char(....)

For me is a simple solution, easy understand, easy coding, easy debugging, easy to migrate and the best works with multiple companies, and the moment does not require API changes, because I had several problems try migrating 4.2 to 4.4., These problems made me think if really ModelSingleton and Multivalue are the best approach for configuration modules, I think that with awesome good design of Tryton, in this case is not necessary.

So I am not expert about performance problems or cache, but maybe is crazy idea we can add some argument to the model as "_cache=True" for solve cache problems, and the core tryton gives the correct treatment and add to cache this model:

class MyModelConfiguration(ModelSQL, ModelView):
    _cache = True
    company = fields.Many2One(.....) # required=True
    sequence_blabla = fields.Many2One('ir.sequence',....)
    parameter1 = fields.Char(....)
msg37131 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2017-12-01.15:23:39
There is a bad performance combination between ModelSingleton and MultiValue.
The singleton is frequently instantiated using '1' as id with the idea that it does not cost anything because values are already in global cache.
The MultiValue used the One2Many field (when available) to benefit from the cache instead of doing a search on each access.
Unfortunately, the combination of both is not optimal because the ModelSingleton uses a new instance each time and the One2Many fields are stored only on the local cache of the instance (not the global). So this generates extra queries after each instantiation to fetch the One2Many.

I think we could fix this by storing a instance for each ModelSingleton in the Transaction cache per context. This cached instance will be reused by ModelSingleton when requesting a new instance. Of course the cache should be cleaned when the singleton is created or deleted.
Date User Action Args
2017-12-24 18:38:26oscarsetstatus: unread -> chatting
nosy: + oscar
messages: + msg37436
2017-12-22 12:57:27pokolisetnosy: + pokoli
2017-12-01 16:55:40restevesetnosy: + resteve
2017-12-01 15:23:39cedcreate

Showing 10 items. Show all history (warning: this could be VERY long)