[Dbix-class] announcing DBIx::Class::Tree::Mobius v0.201

vdg vdg at polygonism.net
Wed Jun 29 16:25:09 GMT 2011


I've released a new version of DBIx::Class::Tree::Mobius.



What's new since the experimental versions (0.00002_01 and 0.00001_04) :

The encoding has changed a bit. So if anyone was using these development
version 0.00002_01 and 0.00001_04, be very careful,
the new encoding is *NOT* compatible with the old one. I can provide a
migration script if you need one.

First change, root nodes are now coded with 'b' column =3D 1 instead of
'null'. Because it's more correct mathematically but also because this
DBIx::Class::Tree::Mobius to manage them more like any other nodes using an
abstract super root node  (a, b, c, d) =3D ( 1, 0, 0, 1 )

This super node is represented internally as a resultset->new({}) empty
object and I use ->in_storage dbic function to test
if a node is the super node or not. I'm not very pleased with this choice
but I was not able to find a better solution. Does someone has an idea?

Secondly, DBIx::Class::Tree::Mobius doesn't store any more a new mobius
representation with a distinct index when inserting a child.
Instead, all leaves (nodes with no child) are using the same encoding with
the position index 2. This is a huge performance
improvement using DBIx::Class::Tree::Mobius with thousands of leaves but
relatively less inner nodes (I guess a case very common
in real world usage of SQL tree encoding).

I've used DBIx::Class::Tree::Mobius in production (MySQL) with several
hundreds of thousand of leaves and 2 thousands inner nodes
without any perceptible slowdown inserting a new child. With the old
encoding of 0.00002_01, adding a new child to a node
already parent of hundred of thousand of children (in this case a 'folder'
of images) could take many seconds.

Another advantage of this lazy allocation of new index - the 'x' of the
M=F6bius encoding (ax+b)/(cx+d) - is that the tree size is only limited
by the number of inner nodes, not by the number of its leaves.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20110629/0c8=

More information about the DBIx-Class mailing list