Am 04.04.2008 um 16:56 schrieb Sebastian Willert:
Guilty as charged, your honor. I still have an half-backed
implementation of DBIx::Class::Tree::NestedSet laying around, that
I've
almost forgotten about. In my defense, I'd stopped working on it
because
I believe we'd need a good RDBMS-independent locking mechanism (and an
live object index for bonus points) for any nested-set
implementation to
become production-ready. In difference to adjacency lists, nested sets
tend to die a horrible dead when used without a good locking strategy
(preferably row-based).
Why can't we use transactions? If someone might want to run nested
sets on a dbms which does not support transactions it is on his own
risk. I think nested sets will only be used in big sites where
retrieving the hole tree or a recursive retrieval is not an option.
And these sites use probably dbms which support transactions.
Those who want trees but have no good dbms have to fall back to the
simple tree approach (parent_id ...)
moritz
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
