"Materialized Paths" Hierarchies and Rails

Rails
1

Folks,

I’ve done some cursory googling and seen nothing promising. . .

I’m interested in implementing an “acts_as_materialized_path” plugin,
which offers a way to model hierarchies in a way that can have
significant advantages over the “adjacency list” provided by
acts_as_tree and the nested set provided by “acts_as_nested_set”.

I’m the author of perl’s DBIx::Tree::NestedSet (
http://cpan.uwinnipeg.ca/dist/DBIx-Tree-NestedSet ), if it matters.

I’d be happy to talk about the relative advantages of the adjacency
list, nested set and materialized path hierarchy models, but that’s not
the point of this posting.

I’m pinging the community to make sure I’m not going to be duplicating
effort and to gauge interest.

Thoughts? Comments? Criticisms? Pointers? Thanks in advance.

-DJCP

2

Hi Daniel,

I’ve been helping Jean-Christophe M. with the Better Nested Set
plugin (http://opensource.symetrie.com/trac/better_nested_set).

I’m interested in anything that offers efficient management of large
hierarchical data-sets in Rails, so I’d love to see a materialized path
implementation. Regarding development, I would like to share thoughts
and ideas (at a minimum, I suppose it would be good if we tried to keep
the APIs similar). In any case, please keep me updated on what you do.

I’m looking at your DBIx module, but as someone who’s never used Perl,
I’m wondering how to generate the documentation (how do you say ‘rake
rdoc’ in Perl?).

You’ve probably already looked at Better Nested Set, but if not, you
can install it with:
script/plugin install
svn://rubyforge.org/var/svn/betternestedset/trunk
then run ‘rake rdoc’ in the betternestedset directory.

Cheers,
Krishna

On Dec 16, 11:22 am, Daniel Collis-puro

3

kpd wrote:

Hi Daniel,

I’ve been helping Jean-Christophe M. with the Better Nested Set
plugin (http://opensource.symetrie.com/trac/better_nested_set).

I’m interested in anything that offers efficient management of large
hierarchical data-sets in Rails, so I’d love to see a materialized path
implementation. Regarding development, I would like to share thoughts
and ideas (at a minimum, I suppose it would be good if we tried to keep
the APIs similar). In any case, please keep me updated on what you do.

I will!

I’m looking at your DBIx module, but as someone who’s never used Perl,
I’m wondering how to generate the documentation (how do you say ‘rake
rdoc’ in Perl?).

You can get the docs online (see the links at the bottom of the page)
at:

http://search.cpan.org/~djcp/DBIx-Tree-NestedSet-0.16/

Or, if you’ve installed the module via CPAN or the normal “perl
Makefile.PL; make ; make test ; make install” dance, via “perldoc
DBIx::Tree::NestedSet” in your console of choice.

BTW, this module has been running in production apps of mine for three
years without a problem. I need to give it another revision, though. . .

You’ve probably already looked at Better Nested Set, but if not, you
can install it with:
script/plugin install
svn://rubyforge.org/var/svn/betternestedset/trunk
then run ‘rake rdoc’ in the betternestedset directory.

I definitely did take a look at it and I plan on testing it and maybe
using it as a model for how my materialized path works. I think it’d be
awesome of have a standard API so that you can easily switch between
schemes.

The big advantage of having a consistent API would be flexibility. For
instance:

Nested sets kick butt in applications where there are many reads but few
updates/deletes, but performance becomes a concern when you start
fiddling with the tree a lot. You need to lock pretty much the entire
tree when you do an update or you could face consistency problems (which
are very hard to fix in a nested set. . . ).

Materialized paths are easily understood, high performance and don’t
require the recursive queries an adjacency list does.

If we had a consistent API, one could swap out hierarchical
representations as an app changes, letting you focus on what your app
needs and what representation suits it best. How cool would it be if
changing between the two plugins would automatically convert the tree
behind the scenes. . .

Maybe the best way we could work together now would be to standardize
the API - I know nested sets pretty well, and we can define an API
that’ll offer the flexibility we need for both implementations.

-DJCP

4

On Dec 16, 3:59 pm, Daniel Collis-puro
[email protected] wrote:

awesome of have a standard API so that you can easily switch between
schemes.

Definitely. Let’s plan on it.

changing between the two plugins would automatically convert the tree
behind the scenes. . .

I’m not sure about automagically adding columns to the table, but we’ve
made the rest of it pretty easy in BetterNestedSet: once you have the
columns, just run a single method and it turns your existing ordinary
(adjacency list) trees into nested sets.

Maybe the best way we could work together now would be to standardize
the API - I knownestedsets pretty well, and we can define an API
that’ll offer the flexibility we need for both implementations.

Sounds like a plan. After you get a chance to look over the
BetterNestedSet API, let us know what changes/extensions you might
want. I’m actually playing with some experimental changes to how our
API works, so I’ll try to get those committed soon.

Would you like to continue this discussion here, or move it to the
BetterNestedSet mailing list?
(http://rubyforge.org/mailman/listinfo/betternestedset-talk)

Cheers, looking forward to hashing it out.

k