FAQ
MojoMojo has a complete nested set implementation in the Page DBIC class.

DBIx::Class::Tree provides a suitable tree API.

There is a nested set branch of DBIx::Class::Tree which I will happily
give out commits bits to on request.

A bunch of you have asked about nested sets, tried to implement them
yourself, been told about this, started on ::Tree implementations, not
had time to carry on, got stuck, forgotten, then somebody else has asked.

Let's get it done.

Anybody who thinks they've got code that's a better starting point than the
MojoMojo stuff, yell.

Then we pick the best one we've got, and port it to provide the ::Tree API.

Anybody willing to doc, tweak, test, or whatever reply here please.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

Search Discussions

  • Charlie Garrison at Mar 31, 2008 at 7:56 pm
    Good morning,

    On 27/3/08 at 9:53 PM -0000, Matt S Trout
    wrote:
    Anybody willing to doc, tweak, test, or whatever reply here please.
    I'm probably one of the people you are referring to. And I
    haven't forgotten about it, but my time/skill is an issue. I'm
    currently using legacy (plain DBI) code to handle the nested
    tree stuff and I'd love to get that converted to DBIC. The
    'select' stuff is easy enough in DBIC but update, insert, delete
    became challenging very quickly.

    I can assist with this, but I don't think I've got enough DBIC
    skills to drive it myself. I would put myself in the 'tweak' and
    'test' category.


    Charlie

    --
    Charlie Garrison <garrison@zeta.org.au>
    PO Box 141, Windsor, NSW 2756, Australia

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    http://www.ietf.org/rfc/rfc1855.txt
  • Matt S Trout at Apr 6, 2008 at 8:38 pm

    On Tue, Apr 01, 2008 at 05:56:17AM +1100, Charlie Garrison wrote:
    Good morning,

    On 27/3/08 at 9:53 PM -0000, Matt S Trout
    wrote:
    Anybody willing to doc, tweak, test, or whatever reply here please.
    I'm probably one of the people you are referring to. And I
    haven't forgotten about it, but my time/skill is an issue. I'm
    currently using legacy (plain DBI) code to handle the nested
    tree stuff and I'd love to get that converted to DBIC. The
    'select' stuff is easy enough in DBIC but update, insert, delete
    became challenging very quickly.
    Except they're -written-.

    http://search.cpan.org/src/MRAMBERG/MojoMojo-0.999013/lib/MojoMojo/Schema/Page.pm

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
  • Charlie Garrison at Apr 7, 2008 at 2:48 pm
    Good evening,

    On 6/4/08 at 8:38 PM +0100, Matt S Trout
    wrote:
    I had seen that before, but I wasn't confident in taking that
    code and creating a generic class (eg.
    DBIx::Class::Tree::NestedSet) or incorporating it directly into
    my code. There was too much code specific to the 'page' metaphor
    for me to separate out the useful NestedSet bits.

    I've had a look at the code Sebastian Willert has done though,
    and it seems like a great start on a generic class. I
    particularly like the grouping_column method in Sebastian's
    solution since I have one table with multiple nested sets.

    Other than the locking issues that Sebastian talks about, what
    are the issues with his code? It looks pretty complete to me. He
    even includes a Tree::NestedSet::Ordered class which means 95%
    of my requirements are already handled. I can start getting rid
    of my legacy DBI code.

    I'm on another project right now, so it will be a couple of
    weeks before I can do anything with Sebastian's code, but I'm
    looking forward to integrating it in my app.


    Charlie

    --
    Charlie Garrison <garrison@zeta.org.au>
    PO Box 141, Windsor, NSW 2756, Australia

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    http://www.ietf.org/rfc/rfc1855.txt
  • Sebastian Willert at Apr 4, 2008 at 3:56 pm

    On Thu, 2008-03-27 at 21:53 +0000, Matt S Trout wrote:
    MojoMojo has a complete nested set implementation in the Page DBIC class.

    DBIx::Class::Tree provides a suitable tree API.

    There is a nested set branch of DBIx::Class::Tree which I will happily
    give out commits bits to on request.

    A bunch of you have asked about nested sets, tried to implement them
    yourself, been told about this, started on ::Tree implementations, not
    had time to carry on, got stuck, forgotten, then somebody else has asked.
    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).
    Anybody who thinks they've got code that's a better starting point than the
    MojoMojo stuff, yell.
    Then we pick the best one we've got, and port it to provide the ::Tree API.
    Tree API is mostly done. IIRC I even ported most of the tests from DBIC::Tree.
    I'd just need a slow day at work to remove some of the cruft that resulted from
    my stab at a home-grown object index, then I'll post it publicly. Until then
    just drop me an email and I'll forward you the polluted tarball...

    Cheers,
    Sebastian
  • Moritz Onken at Apr 5, 2008 at 4:06 pm

    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
  • Sebastian Willert at Apr 5, 2008 at 5:00 pm

    On Sat, 2008-04-05 at 17:06 +0200, Moritz Onken wrote:
    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 ...)
    Unfortunately it's not as easy as this. Off the top of my head:
    transactional isolation just prevents dirty reads wrt. this problem,
    i.E. reading an inconsistent state. If two concurrent operations want to
    change the same tree they are not forced to wait for the other one to
    complete but start operation on the same initial state unless locking is
    employed. This would seriously butcher the nesting information.

    Have a look at
    http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html for a
    short discussion (and yeah, I know mysql doesn't necessarily count as a
    good RDBMS).

    Cheers,
    Sebastian
  • Moritz Onken at Apr 5, 2008 at 5:50 pm

    Am 05.04.2008 um 18:00 schrieb Sebastian Willert:
    Unfortunately it's not as easy as this. Off the top of my head:
    transactional isolation just prevents dirty reads wrt. this problem,
    i.E. reading an inconsistent state.
    Understood. But the transaction could include a read which checks
    whether the tree is still what it used to be and then update. This way
    the first part of the transaction (read) has to wait for a concurrent
    update. Am I wrong?

    If so, a workaround could be some sub-classes which specify the dbms
    specific commands (DBIC::(Tree::)Lock::PostgreSQL?).
  • Matt S Trout at Apr 6, 2008 at 8:41 pm

    On Fri, Apr 04, 2008 at 04:56:57PM +0200, Sebastian Willert wrote:
    On Thu, 2008-03-27 at 21:53 +0000, Matt S Trout wrote:
    MojoMojo has a complete nested set implementation in the Page DBIC class.

    DBIx::Class::Tree provides a suitable tree API.

    There is a nested set branch of DBIx::Class::Tree which I will happily
    give out commits bits to on request.

    A bunch of you have asked about nested sets, tried to implement them
    yourself, been told about this, started on ::Tree implementations, not
    had time to carry on, got stuck, forgotten, then somebody else has asked.
    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).
    And as I said at the time to you, you believe wrong and could we please
    just have an implementation that mostly works first?

    You basically wasted your time disappearing down a rathole that a lot of
    yours consumers won't need.

    Yes, without an LOI you can end up with dirty objects. But you can always
    end up with dirty objects in DBIC; that's how it works.

    Especially for web applications, dirty objects really don't matter since your
    request cycle tends to be "load some data, perform an update, throw the
    objects away".

    Stop overengineering and put some damn code in the repo :P

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
  • Sebastian Willert at Apr 7, 2008 at 3:12 pm

    On Sun, 2008-04-06 at 20:41 +0100, Matt S Trout wrote:
    On Fri, Apr 04, 2008 at 04:56:57PM +0200, Sebastian Willert wrote:
    On Thu, 2008-03-27 at 21:53 +0000, Matt S Trout wrote:
    A bunch of you have asked about nested sets, tried to implement them
    yourself, been told about this, started on ::Tree implementations, not
    had time to carry on, got stuck, forgotten, then somebody else has asked.
    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).
    And as I said at the time to you, you believe wrong and could we please
    just have an implementation that mostly works first?

    You basically wasted your time disappearing down a rathole that a lot of
    yours consumers won't need.

    Yes, without an LOI you can end up with dirty objects. But you can always
    end up with dirty objects in DBIC; that's how it works.
    You are building a straw-man here. I blocked on locking support, not on
    LOI. The sane approach here would be to take Moritz suggestion with
    locking-support factored out into RDBMS-specific subclasses (or, even
    better, delegated to them to avoid mocking around with ISA).

    I'll happily provide the statements needed for MySQL InnoDB and help out
    with the factoring when I'm done with the work-related stuff that's
    overwhelming me right now ... should be in one or two weeks.

    Cheers,
    Sebastian
  • Matt S Trout at Apr 10, 2008 at 6:41 pm

    On Mon, Apr 07, 2008 at 04:12:27PM +0200, Sebastian Willert wrote:
    On Sun, 2008-04-06 at 20:41 +0100, Matt S Trout wrote:
    On Fri, Apr 04, 2008 at 04:56:57PM +0200, Sebastian Willert wrote:
    On Thu, 2008-03-27 at 21:53 +0000, Matt S Trout wrote:
    A bunch of you have asked about nested sets, tried to implement them
    yourself, been told about this, started on ::Tree implementations, not
    had time to carry on, got stuck, forgotten, then somebody else has asked.
    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).
    And as I said at the time to you, you believe wrong and could we please
    just have an implementation that mostly works first?

    You basically wasted your time disappearing down a rathole that a lot of
    yours consumers won't need.

    Yes, without an LOI you can end up with dirty objects. But you can always
    end up with dirty objects in DBIC; that's how it works.
    You are building a straw-man here. I blocked on locking support, not on
    LOI. The sane approach here would be to take Moritz suggestion with
    locking-support factored out into RDBMS-specific subclasses (or, even
    better, delegated to them to avoid mocking around with ISA).
    Why locking support? SELECT FOR UPDATE should do the trick shouldn't it?

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
  • Sebastian Willert at Apr 10, 2008 at 6:53 pm

    On Thu, 2008-04-10 at 18:41 +0100, Matt S Trout wrote:
    On Mon, Apr 07, 2008 at 04:12:27PM +0200, Sebastian Willert wrote:
    On Sun, 2008-04-06 at 20:41 +0100, Matt S Trout wrote:
    On Fri, Apr 04, 2008 at 04:56:57PM +0200, Sebastian Willert wrote:
    On Thu, 2008-03-27 at 21:53 +0000, Matt S Trout wrote:
    A bunch of you have asked about nested sets, tried to implement them
    yourself, been told about this, started on ::Tree implementations, not
    had time to carry on, got stuck, forgotten, then somebody else has asked.
    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).
    And as I said at the time to you, you believe wrong and could we please
    just have an implementation that mostly works first?

    You basically wasted your time disappearing down a rathole that a lot of
    yours consumers won't need.

    Yes, without an LOI you can end up with dirty objects. But you can always
    end up with dirty objects in DBIC; that's how it works.
    You are building a straw-man here. I blocked on locking support, not on
    LOI. The sane approach here would be to take Moritz suggestion with
    locking-support factored out into RDBMS-specific subclasses (or, even
    better, delegated to them to avoid mocking around with ISA).
    Why locking support? SELECT FOR UPDATE should do the trick shouldn't it?
    In MySQL with InnoDB yes, in MySQL with MyISAM and SQLite no, even
    crashing the process. No idea about all the other DBs out there. If
    'SELECT FOR UPDATE' is considered compatible enough, I will gladly use
    it directly with a big fat warning in the POD. MyISAM and SQLite could
    be regarded as unfit for this purpose without anyone shedding a tear
    IMO.

    So, people with easy access to other DBs, speak up.

    Cheers, Sebastian
  • Matt S Trout at Apr 11, 2008 at 3:39 pm

    On Thu, Apr 10, 2008 at 07:53:42PM +0200, Sebastian Willert wrote:
    Why locking support? SELECT FOR UPDATE should do the trick shouldn't it?
    In MySQL with InnoDB yes, in MySQL with MyISAM and SQLite no, even
    crashing the process. No idea about all the other DBs out there. If
    'SELECT FOR UPDATE' is considered compatible enough, I will gladly use
    it directly with a big fat warning in the POD. MyISAM and SQLite could
    be regarded as unfit for this purpose without anyone shedding a tear
    IMO.
    SQLite won't allow parallel updates at all anyway so I figure it can be
    convinced to lock the entire database for us.

    Postgres handles FOR UPDATE. MyISAM can go anally violate itself with a
    brick for all I care.

    As for anything else, I think doc "needs FOR UPDATE, if your DB doesn't have
    it patches welcome" and call it good for a first release - half-working code
    is better than no code at all.

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbix-class @
categoriesperl, catalyst
postedMar 27, '08 at 9:53p
activeApr 11, '08 at 3:39p
posts13
users4
websitedbix-class.org
irc#dbix-class

People

Translate

site design / logo © 2022 Grokbase