Jens Seipenbusch wrote:
thx alot Geoff for helping me that fast and sorry for bugging you again.
in fact its not easy for me to decipher the inner workings of farcry
since i'm not a developer myself.
Currently we do nightly backups every day, because we still have
sometimes problems with the tree that make it necessary to restore the
whole db. if version 2.4 uses the same tree-code i sure must dive deeper
into the related code, e.g. to remove orphans and track our problems..
Tree management is an ongoing issue. Although there's never any data
loss, in large trees its becoming increasingly common that folks get
tree "glitches" or corruption in the tree hierarchy metadata. We now
have two very robust utilities for repairing this. But heh.. the best
thing would be to stop these issues occurring at all.
The reason why we get these glitches is invariably people doing tree
moves (including send to trash) and then performing some additional tree
changes (including adding folders) before the initial process has
completed. Typically this means folks with established sites and fewer
tree moves rarely see issues, those starting out or doing major
renovation tend to encounter the problem more often.
With regard to tree management... patience is a virtue :)
Technically the tree is very *read* optimised. It is incredibly quick
at getting navigation content and the like regardless of size. This
comes att he cost of resource intensive tasks to make tree changes.
Moving forward we're trying to implement much stricter locking of tree
changes to prevent people causing issues in the first place. Or
alternatively, change the underlying tree management completely and move
the read optimised nested tree model into memory and out of the database.
Hope that helps folks understand things a little better.
-- geoff
http://www.daemon.com.au/
---
You are currently subscribed to farcry-dev as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/
