* Cédric Krier [2011-03-09 15:58 +0100]:
The numbers show clearly that we need some smarter MPTT update handling. The
included server patch gave us at least the possibilty to control the MPTT
update with minimal invasive coding by context handling, running without
problems in production. Probably better would be the extension of the signatures
of create, write and delete with named argument tree_update=True. Since it is
very useful to have such control I am asking for inclusion.
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.
I think it will be better to work on having the create method working for
creation of many records.
Since marking the tree as dirty and recomputing it before search
queries is not possible due to the lack of transaction.
I think that this kind of problem is best solved by improving the way
bulk insert are done too. Because delaying the computation is clearly
a bad idea, you never know what code will be executed between your
inserts and your MPTT recomputation.
--
(°> Nicolas Évrard
( ) Liège
`¯
--
[email protected] mailing list
