Store unit_price_digits config setting in the database

Feature Ideas
1

Tryton has configuration forms that are used to store most settings that affect the behaviour of the system. There’s also a configuration file but most of the time that configuration file is used for system-specific settings:

  • The path of the attachments
  • What IP or port it must listen to
  • URI of the database
  • etc

However, there’s the unit_price_digits setting that does not depend on the system and affects the behaviour of Tryton but that is stored in trytond.conf. It seems to me that it’s easy to mess things to have unit_price_digits in trytond.conf and is not consistent with other settings. Otherwise, why do we store the main language in “ir.configuration”? Or why don’t we have a flag in trytond.conf to set the default invoicing policy of sales?

I think that when unit_price_digits was introduced it was added to the configuration file justified by performance reasons. However, I think recently we’ve seen that getting settings from the configuration file was not cheap either, and anyway we’re doing lots of other database access for getting settings (number of digits of quantities, default accounts, etc) and we even have a cache to manage all that.

So my proposal would be to store “unit_price_digits” as a field in “product.configuration” model.

This ensures that when you restore the database you’ve got almost everything that is necessary to make it work as the backed-up one, except, of course for the system-specific settings that cannot be “copied” from one system to the other because IPs, ports, databases, or paths will probably change.

Thoughts?

2

No, it is a configuration because it defined how the schema of the database (when digits constraint was set in the database schema).

Still way more cheaper than database access.

I think that storing it there will give the feeling that it can be modified at will but it is not the case. This can almost never be changed without proper migration except by increasing.
So I think a better place would be ir.configuration which is not usable from UI.

Also I would prefer to avoid the creation of Function field everywhere just to be able to evaluate the digits. And also because it would give again the feeling to developer that it can be tune case by case. This must stay a global static value at least per database (or per configuration).
So I think we should have a object that can store and fetch the value on demand. A little by like the lazy_gettext.

1 Like
3

Ok. Sounds good to me.

4

I have submitted Issue 9324: Check against misconfiguration of price_digits - Tryton issue tracker which adds protection against bad configuration.