Hi, Am Donnerstag, den 10.03.2011, 12:36 +0100 schrieb Cédric Krier: > On 10/03/11 12:26 +0100, Bertrand Chenal wrote: > > Le Wed, 9 Mar 2011 15:58:17 +0100, > > Cédric Krier <[email protected]> a écrit : > > > > > > > > Furthermore we should evaluate the possibilities to delay the MPTT > > > > update till the end of any encapsulating transaction. The idea is > > > > to run the MPTT update only at the end of the first of perhaps > > > > multiple nested transaction. > > > > > > > > Comments and thoughts welcome. > > > > > > I don't find that delaying or postpone the update of MPTT is a good > > > idea. Because the system is build on the assumption that it can use > > > MPTT for search at any time, so inside the same transaction you could > > > use it just after modification of the tree. > > > > What about delaying it only until the next search (I.E, write/create > > mark the tree as dirty, search trigger mptt computation if the tree > > is dirty) ? Like that the assumption is still valid, but massive insert > > is not affected. > > I don't like too much that a search modify the tree. > And more over, search rpc calls are done in a non-commited transaction. The problem is a serious slow-down off massive batch data entries. As far as I understand Cédric, Matthias idea has the issue, that some other user could try to search/read faulty records, while the data is imported i a batch. So why not create a kind of maintenance mode for Tryton, which allows only one user to login and reject the others with a message? With this mode we can run batch data import at night with yangoons patch, and avoid that other users can retrieve wrong data from Tryton.
Regards -- Udo Spallek ------------------------------------ virtual things Preisler & Spallek GbR Munich - Aix-la-Chapelle Windeckstr. 77 81375 Munich - Germany Tel: +49 (89) 710 481 55 Fax: +49 (89) 710 481 56 [email protected] http://www.virtual-things.biz -- [email protected] mailing list
