Le Thu, 10 Mar 2011 12:36:31 +0100, Cédric Krier <[email protected]> a écrit :
> 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. > Another solution is to drop mptt and use a closure table[1], it seems to generate far less queries to maintain the index. [1] http://dirtsimple.org/2010/11/simplest-way-to-do-tree-based-queries.html -- Bertrand Chenal B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email: [email protected] Website: http://www.b2ck.com/ -- [email protected] mailing list
