On 17 Jul 00:57, Dominique Chabord wrote: > Le 16/07/2014 15:29, Cédric Krier a écrit : > > On 16 Jul 14:43, Dominique Chabord wrote: > >> Hello, > >> I think this option is required and should be defined per database and > >> not in configuration file. > > > > Soon it will be the same as one database per process. > > This is not a valid argument. If Tryton runs a single database at a > time, it can run several databases one after the other.
Don't understand. > Nevertheless > will Tryton be single company too ? because this parameter is company > dependant. Tryton is already mainly single company, it is a fact see previous discussion about multi-company. I don't see any advantage to have multi-company if it is to have everything different. Here, I just apply the KISS principle. > > Also I don't want to have it in the database for many reasons: > > > > - can not really be changed > > There are many things in the database which cannot be changed and if it > cannot be changed, it enforces the fact that it has nothing to do in the > start configuration of the process. What about a module ? So you want to create a module for just setup a flag? > > - will cost too much to read each time > > Then replace the database by a big config file, and you will be fast ;-) > Out of curiosity, why do you need to read each time from the database > and one time from the config file ? Because configuration is by definition static. Data in the database are not. > And why is it different for other > company-related data ? What have you in mind? > > There will be more and more things going in the configuration file like > > the all ldap_connection module, the price digits etc. > > price digits and sum ordering are given accounting parameters of a > company. Two companies need different values. If two companies need different values, they should be managed by different instance. Once again, mutli-company is a dream. Nobody ever achieve to make it works out side of simple case (like subsidiary). If companies don't share the same rules, they have nothing to do in the same database. > >> Btw, if implemented in conf file, how would the history behave when > >> conf is changed ? or when database is restored ? > > > > People should be careful to not shoot their own foot. > > tryton must be manageable too. Exactly, that's why all those stuff should be in a configuration file. > For restoring any archive of a database > you will need to know about the configuration file of the original > server, adapt some parameters on your local server and start it. Yes and you will also need to know the version of the source code executed. > The configuration file should define parameters related to the execution > context and should not depend on the database you restore. That's wrong. You can not manage data independently of the code, they are the same. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpK23PVTJ2pe.pgp
Description: PGP signature
