From raasdnil at gmail.com  Thu Jul  5 05:09:15 2007
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Thu, 5 Jul 2007 19:09:15 +1000
Subject: [Betternestedset-talk] Virtual roots
Message-ID: <57a815bf0707050209s7830b175j4324a7b6e3fbdebc@mail.gmail.com>

I've got a tree with virtual roots scoped on a foreign_id key.

This works.

However, if I try to move a root to the child of another node, I get
the following error (pasted below).

Is this correct behaviour?  Does this mean once you create a node, it
can not move into another tree?

If this is the case... does that mean the only way to move a node into
another tree is to delete and re-create it?

Thanks

Mikel

Error follows:

?> p1
=> #<Paragraph:0x3565150 @attributes={"text"=>nil, "section_id"=>"1",
"lft"=>"1", "id"=>"1", "parent_id"=>nil, "rgt"=>"2"}>
>> p2
=> #<Paragraph:0x3553b30 @attributes={"text"=>nil, "section_id"=>"2",
"lft"=>"1", "id"=>"2", "parent_id"=>nil, "rgt"=>"2"}>
>> p2.move_to_child_of(p1.id)
ActiveRecord::ActiveRecordError: Impossible move, target node cannot
be inside moved tree.
        from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:933:in
`move_to'
        from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:1109:in
`with_optional_transaction'
        from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/database_statements.rb:59:in
`transaction'
        from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/transactions.rb:95:in
`transaction'
        from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/transactions.rb:121:in
`transaction'
        from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:1109:in
`with_optional_transaction'
        from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:924:in
`move_to'
        from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:865:in
`move_to_child_of'
        from (irb):68
>>

From dontfall at gmail.com  Thu Jul  5 08:53:09 2007
From: dontfall at gmail.com (Krishna Dole)
Date: Thu, 5 Jul 2007 08:53:09 -0400
Subject: [Betternestedset-talk] Virtual roots
In-Reply-To: <57a815bf0707050209s7830b175j4324a7b6e3fbdebc@mail.gmail.com>
References: <57a815bf0707050209s7830b175j4324a7b6e3fbdebc@mail.gmail.com>
Message-ID: <8d64b97d0707050553v1f2dc4b6y4313988d28ce6b2d@mail.gmail.com>

yes and yes. currently nodes cannot be moved between trees (though
this behavior could be added). the (admittedly klunky) workaround is
to delete the node from one tree and create it in another.

krishna

On 7/5/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> I've got a tree with virtual roots scoped on a foreign_id key.
>
> This works.
>
> However, if I try to move a root to the child of another node, I get
> the following error (pasted below).
>
> Is this correct behaviour?  Does this mean once you create a node, it
> can not move into another tree?
>
> If this is the case... does that mean the only way to move a node into
> another tree is to delete and re-create it?
>
> Thanks
>
> Mikel
>
> Error follows:
>
> ?> p1
> => #<Paragraph:0x3565150 @attributes={"text"=>nil, "section_id"=>"1",
> "lft"=>"1", "id"=>"1", "parent_id"=>nil, "rgt"=>"2"}>
> >> p2
> => #<Paragraph:0x3553b30 @attributes={"text"=>nil, "section_id"=>"2",
> "lft"=>"1", "id"=>"2", "parent_id"=>nil, "rgt"=>"2"}>
> >> p2.move_to_child_of(p1.id)
> ActiveRecord::ActiveRecordError: Impossible move, target node cannot
> be inside moved tree.
>         from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:933:in
> `move_to'
>         from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:1109:in
> `with_optional_transaction'
>         from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/database_statements.rb:59:in
> `transaction'
>         from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/transactions.rb:95:in
> `transaction'
>         from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/transactions.rb:121:in
> `transaction'
>         from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:1109:in
> `with_optional_transaction'
>         from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:924:in
> `move_to'
>         from ./script/../config/../config/../vendor/plugins/betternestedset/lib/better_nested_set.rb:865:in
> `move_to_child_of'
>         from (irb):68
> >>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>

From jc.michel at symetrie.com  Thu Jul  5 08:31:35 2007
From: jc.michel at symetrie.com (Jean-Christophe Michel)
Date: Thu, 5 Jul 2007 14:31:35 +0200
Subject: [Betternestedset-talk] Virtual roots
In-Reply-To: <57a815bf0707050209s7830b175j4324a7b6e3fbdebc@mail.gmail.com>
References: <57a815bf0707050209s7830b175j4324a7b6e3fbdebc@mail.gmail.com>
Message-ID: <B9F0C30D-2461-4B3A-9638-8DBE46FFEB11@symetrie.com>

Hi,


Le 5 juil. 07 ? 11:09, Mikel Lindsaar a ?crit :
> However, if I try to move a root to the child of another node, I get
> the following error (pasted below).
>
> Is this correct behaviour?  Does this mean once you create a node, it
> can not move into another tree?
>
> If this is the case... does that mean the only way to move a node into
> another tree is to delete and re-create it?

Seems that scope is ignored when preventing move of nodes ;-)

Jean-Christophe Michel
--
symetrie.com

Better Nested Set for rails:
http://opensource.symetrie.com/trac/better_nested_set



From jmischo at quagility.com  Thu Jul  5 09:03:55 2007
From: jmischo at quagility.com (Jonathan Mischo)
Date: Thu, 5 Jul 2007 08:03:55 -0500
Subject: [Betternestedset-talk] Virtual roots
In-Reply-To: <B9F0C30D-2461-4B3A-9638-8DBE46FFEB11@symetrie.com>
Message-ID: <003601c7bf04$f2cd6570$0132a8c0@tazlore.com>

Hey all,

This behavior was fixed in my code by a combination of the patch I emailed
out a while ago and a very simple conditional check.  If you move a node up
to be its parent's peer, you can then make the former parent a subordinate
value of its subtree.  That is the case in which you generally get the error
below.  I have code that actually allows you to directly set a parent to be
a child of one of its children...this code promotes all of the parent's
children to be its peers, and then moves the parent node into the target
subtree.  It works very well, no errors, etc.

I'd be happy to demonstrate, but I've got places to be today.  Perhaps
tomorrow evening, if this is of interest?

-Jon

-----Original Message-----
From: betternestedset-talk-bounces at rubyforge.org
[mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of
Jean-Christophe Michel
Sent: Thursday, July 05, 2007 7:32 AM
To: betternestedset-talk at rubyforge.org
Subject: Re: [Betternestedset-talk] Virtual roots

Hi,


Le 5 juil. 07 ? 11:09, Mikel Lindsaar a ?crit :
> However, if I try to move a root to the child of another node, I get
> the following error (pasted below).
>
> Is this correct behaviour?  Does this mean once you create a node, it
> can not move into another tree?
>
> If this is the case... does that mean the only way to move a node into
> another tree is to delete and re-create it?

Seems that scope is ignored when preventing move of nodes ;-)

Jean-Christophe Michel
--
symetrie.com

Better Nested Set for rails:
http://opensource.symetrie.com/trac/better_nested_set


_______________________________________________
Betternestedset-talk mailing list
Betternestedset-talk at rubyforge.org
http://rubyforge.org/mailman/listinfo/betternestedset-talk


From raasdnil at gmail.com  Thu Jul  5 18:42:21 2007
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Fri, 6 Jul 2007 08:42:21 +1000
Subject: [Betternestedset-talk] Virtual roots
In-Reply-To: <003601c7bf04$f2cd6570$0132a8c0@tazlore.com>
References: <B9F0C30D-2461-4B3A-9638-8DBE46FFEB11@symetrie.com>
	<003601c7bf04$f2cd6570$0132a8c0@tazlore.com>
Message-ID: <57a815bf0707051542m1c3a6951td65502ddd78e3f9@mail.gmail.com>

Wow, thanks for all you fast replies!  Great list :)

Jon, that would be great :)  Maybe we could wrap it up better and add
it into better nested set?

Regards

Mikel

On 7/5/07, Jonathan Mischo <jmischo at quagility.com> wrote:
> Hey all,
>
> This behavior was fixed in my code by a combination of the patch I emailed
> out a while ago and a very simple conditional check.  If you move a node up
> to be its parent's peer, you can then make the former parent a subordinate
> value of its subtree.  That is the case in which you generally get the error
> below.  I have code that actually allows you to directly set a parent to be
> a child of one of its children...this code promotes all of the parent's
> children to be its peers, and then moves the parent node into the target
> subtree.  It works very well, no errors, etc.
>
> I'd be happy to demonstrate, but I've got places to be today.  Perhaps
> tomorrow evening, if this is of interest?
>
> -Jon
>
> -----Original Message-----
> From: betternestedset-talk-bounces at rubyforge.org
> [mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of
> Jean-Christophe Michel
> Sent: Thursday, July 05, 2007 7:32 AM
> To: betternestedset-talk at rubyforge.org
> Subject: Re: [Betternestedset-talk] Virtual roots
>
> Hi,
>
>
> Le 5 juil. 07 ? 11:09, Mikel Lindsaar a ?crit :
> > However, if I try to move a root to the child of another node, I get
> > the following error (pasted below).
> >
> > Is this correct behaviour?  Does this mean once you create a node, it
> > can not move into another tree?
> >
> > If this is the case... does that mean the only way to move a node into
> > another tree is to delete and re-create it?
>
> Seems that scope is ignored when preventing move of nodes ;-)
>
> Jean-Christophe Michel
> --
> symetrie.com
>
> Better Nested Set for rails:
> http://opensource.symetrie.com/trac/better_nested_set
>
>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>

From jmischo at quagility.com  Thu Jul  5 23:35:45 2007
From: jmischo at quagility.com (Jonathan Mischo)
Date: Thu, 5 Jul 2007 22:35:45 -0500
Subject: [Betternestedset-talk] Virtual roots
In-Reply-To: <57a815bf0707051542m1c3a6951td65502ddd78e3f9@mail.gmail.com>
Message-ID: <00c801c7bf7e$bd43a520$0132a8c0@tazlore.com>

I'm not a committer, so I don't think I can.  The code I modified mainly
just simplified some of the code to make it work in a way that I felt was
more sensible.  On further reflection, though, I believe that it doesn't
QUITE fix the scoping issue...more that it just defaults sensibly.  I need
to review my code a bit more, but I did send the patch to the list.

I'll definitely send some examples of how to work with this aspect, though,
and perhaps work on recoding some of the scoping stuff when I have a little
time (which won't be for at least a week or two).

-Jon

-----Original Message-----
From: betternestedset-talk-bounces at rubyforge.org
[mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of Mikel
Lindsaar
Sent: Thursday, July 05, 2007 5:42 PM
To: betternestedset-talk at rubyforge.org
Subject: Re: [Betternestedset-talk] Virtual roots

Wow, thanks for all you fast replies!  Great list :)

Jon, that would be great :)  Maybe we could wrap it up better and add
it into better nested set?

Regards

Mikel

On 7/5/07, Jonathan Mischo <jmischo at quagility.com> wrote:
> Hey all,
>
> This behavior was fixed in my code by a combination of the patch I emailed
> out a while ago and a very simple conditional check.  If you move a node
up
> to be its parent's peer, you can then make the former parent a subordinate
> value of its subtree.  That is the case in which you generally get the
error
> below.  I have code that actually allows you to directly set a parent to
be
> a child of one of its children...this code promotes all of the parent's
> children to be its peers, and then moves the parent node into the target
> subtree.  It works very well, no errors, etc.
>
> I'd be happy to demonstrate, but I've got places to be today.  Perhaps
> tomorrow evening, if this is of interest?
>
> -Jon
>
> -----Original Message-----
> From: betternestedset-talk-bounces at rubyforge.org
> [mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of
> Jean-Christophe Michel
> Sent: Thursday, July 05, 2007 7:32 AM
> To: betternestedset-talk at rubyforge.org
> Subject: Re: [Betternestedset-talk] Virtual roots
>
> Hi,
>
>
> Le 5 juil. 07 ? 11:09, Mikel Lindsaar a ?crit :
> > However, if I try to move a root to the child of another node, I get
> > the following error (pasted below).
> >
> > Is this correct behaviour?  Does this mean once you create a node, it
> > can not move into another tree?
> >
> > If this is the case... does that mean the only way to move a node into
> > another tree is to delete and re-create it?
>
> Seems that scope is ignored when preventing move of nodes ;-)
>
> Jean-Christophe Michel
> --
> symetrie.com
>
> Better Nested Set for rails:
> http://opensource.symetrie.com/trac/better_nested_set
>
>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>
_______________________________________________
Betternestedset-talk mailing list
Betternestedset-talk at rubyforge.org
http://rubyforge.org/mailman/listinfo/betternestedset-talk


From christian at unit12.net  Fri Jul  6 15:41:23 2007
From: christian at unit12.net (Christian Niles)
Date: Fri, 6 Jul 2007 15:41:23 -0400
Subject: [Betternestedset-talk] patch to add update conditions
Message-ID: <422CDC87-F99D-4B60-BB84-4F3EB85D3CEA@unit12.net>

Hi All,

I've written (and attached) a patch that adds additional WHERE  
conditions to the UPDATE statement used in the move_to method.

The conditions added are the same as those in the various CASE  
clauses, but by duplicating them in the WHERE clause, the database  
can take advantage of indices on the table. The previous UPDATE  
statement, without the extra conditions, would end up iterating  
through the entire tree. I assume it was smart enough to notice when  
a row wasn't actually changed, but for a tiny update of a large tree,  
it adds up.

FYI, I have a multi-column index on my table, which includes the  
scope column, as well as the left and right columns. E.g.:

	add_index :tree_items, [:scope_id, :lft, :rgt]

I've tested using PostgreSQL, so it might be nice to hear from  
someone using MySQL and other databases.

thanks!
christian.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bns_update_conditions.patch
Type: application/octet-stream
Size: 1377 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/betternestedset-talk/attachments/20070706/ee64891a/attachment.obj 

From dontfall at gmail.com  Fri Jul  6 16:25:45 2007
From: dontfall at gmail.com (Krishna Dole)
Date: Fri, 6 Jul 2007 16:25:45 -0400
Subject: [Betternestedset-talk] patch to add update conditions
In-Reply-To: <422CDC87-F99D-4B60-BB84-4F3EB85D3CEA@unit12.net>
References: <422CDC87-F99D-4B60-BB84-4F3EB85D3CEA@unit12.net>
Message-ID: <8d64b97d0707061325p66c46990i6ac9833cede21682@mail.gmail.com>

Hi Christian,

Thanks for submitting a patch.

Are you seeing significant performance gains with this patch? Have you
benchmarked performance with different index setups? I'm reluctant to
commit a performance patch without good benchmarks. I've personally
seen unexpected results from what I thought would be straightforward
performance improvements (adding indexes just slowed the updates down
because the indexes needed to be refreshed on update, extra conditions
in the where clause didn't help, etc.).

best,
Krishna

On 7/6/07, Christian Niles <christian at unit12.net> wrote:
> Hi All,
>
> I've written (and attached) a patch that adds additional WHERE
> conditions to the UPDATE statement used in the move_to method.
>
> The conditions added are the same as those in the various CASE
> clauses, but by duplicating them in the WHERE clause, the database
> can take advantage of indices on the table. The previous UPDATE
> statement, without the extra conditions, would end up iterating
> through the entire tree. I assume it was smart enough to notice when
> a row wasn't actually changed, but for a tiny update of a large tree,
> it adds up.
>
> FYI, I have a multi-column index on my table, which includes the
> scope column, as well as the left and right columns. E.g.:
>
>         add_index :tree_items, [:scope_id, :lft, :rgt]
>
> I've tested using PostgreSQL, so it might be nice to hear from
> someone using MySQL and other databases.
>
> thanks!
> christian.
>
>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>
>
>

From christian at unit12.net  Sat Jul  7 12:25:13 2007
From: christian at unit12.net (Christian Niles)
Date: Sat, 7 Jul 2007 12:25:13 -0400
Subject: [Betternestedset-talk] patch to add update conditions
In-Reply-To: <8d64b97d0707061325p66c46990i6ac9833cede21682@mail.gmail.com>
References: <422CDC87-F99D-4B60-BB84-4F3EB85D3CEA@unit12.net>
	<8d64b97d0707061325p66c46990i6ac9833cede21682@mail.gmail.com>
Message-ID: <64876B13-5A08-40BF-9029-7D13982A241D@unit12.net>

Hey Krishna,

I did some informal benchmarks for my own data, but some more  
specific ones are in order. My own observations showed that without  
the checks, the time taken for an UPDATE increased linearly. With the  
conditions, update time swayed from as little as a few milliseconds  
to a few seconds, depending on how many rows were updated. So my  
patch essentially halved the average

As a test, I just tried something. I ran an UPDATE statement that set  
the value of a column to its current value -- in effect, it doesn't  
change it at all. E.g.

	UPDATE table SET id = id;

PostgreSQL re-wrote all rows to disk, which explains the linear  
performance I noticed -- even a small UPDATE caused every row of the  
table to be rewritten. MySQL 5, however, noticed that rows hadn't  
been changed and didn't write the rows to disk.

I also realized that my patch *should* improve performance, even  
without any extra indices on the table. All it's doing is pre- 
evaluating the CASE conditions in the WHERE clause, which gives the  
database an earlier heads up that the row should or shouldn't change.

Anyway, I'm getting more convinced that this did improve actual  
performance on PostgreSQL, rather than just perceived performance.  
I'll put together some test cases and benchmarks in the next few days  
so we can test it out on different databases and configurations.

best,
christian.

On Jul 6, 2007, at 4:25 PM, Krishna Dole wrote:

> Hi Christian,
>
> Thanks for submitting a patch.
>
> Are you seeing significant performance gains with this patch? Have you
> benchmarked performance with different index setups? I'm reluctant to
> commit a performance patch without good benchmarks. I've personally
> seen unexpected results from what I thought would be straightforward
> performance improvements (adding indexes just slowed the updates down
> because the indexes needed to be refreshed on update, extra conditions
> in the where clause didn't help, etc.).
>
> best,
> Krishna
>
> On 7/6/07, Christian Niles <christian at unit12.net> wrote:
>> Hi All,
>>
>> I've written (and attached) a patch that adds additional WHERE
>> conditions to the UPDATE statement used in the move_to method.
>>
>> The conditions added are the same as those in the various CASE
>> clauses, but by duplicating them in the WHERE clause, the database
>> can take advantage of indices on the table. The previous UPDATE
>> statement, without the extra conditions, would end up iterating
>> through the entire tree. I assume it was smart enough to notice when
>> a row wasn't actually changed, but for a tiny update of a large tree,
>> it adds up.
>>
>> FYI, I have a multi-column index on my table, which includes the
>> scope column, as well as the left and right columns. E.g.:
>>
>>         add_index :tree_items, [:scope_id, :lft, :rgt]
>>
>> I've tested using PostgreSQL, so it might be nice to hear from
>> someone using MySQL and other databases.
>>
>> thanks!
>> christian.
>>
>>
>> _______________________________________________
>> Betternestedset-talk mailing list
>> Betternestedset-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>>
>>
>>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk


From christian at unit12.net  Sat Jul  7 17:36:01 2007
From: christian at unit12.net (Christian Niles)
Date: Sat, 7 Jul 2007 17:36:01 -0400
Subject: [Betternestedset-talk] Benchmarks for update_conditions.patch
Message-ID: <7FF42484-083A-470E-B51A-992E34861041@unit12.net>

I spent some time this afternoon developing benchmarks for the patch  
I submitted yesterday. I tested both MySQL and PostgreSQL, using  
topic names from dmoz.org. The results are pretty striking:

# 667 Topics (3 Levels Deep)

* MySQL, unpatched:		12.5s
* MySQL, patched:		12.1s

* PgSQL, unpatched:		1457.7s
* PgSQL, patched:		14.1s

# 8308 Topics (4 Levels Deep)

* MySQL, unpatched:		660.1s
* MySQL, patched:		533.8s

* PgSQL, unpatched:		226469.1s (estimated*)
* PgSQL, patched:		478.4s

As you can see, there is a modest improvement for MySQL, but a *huge*  
difference for PostgreSQL. I had thought that it was due to the  
indices, but now I'm sure it's due to the fact that PostgreSQL writes  
unchanged rows in the UPDATE clause. As a result, everytime an object  
is moved in the tree, every single row gets rewritten to disk, and  
performance deteriorates quickly.

It's worth noting that my tests add Topics in depth-first order, so  
each UPDATE should only need to update a few rows. So the results  
showcase the best possible improvement. The extra conditions won't  
help at all when the database actually needs to change every row in  
the database.

I've uploaded copies of the test applications here:

http://unit12.net/hot_topics.tar.gz
http://unit12.net/hot_topics_patched.tar.gz

The tests can be run using script/runner like so:

	$ ./script/runner ./script/benchmark_bns.rb

The data used is in db/topics.yml, which is generated (via rake) from  
the data in db/dmoz_topics.txt:

	$ rake db/topics.yml

The db/dmoz_topics.txt file was produced from the Open Directory  
(dmoz.org) data at:

	http://rdf.dmoz.org/rdf/structure.rdf.u8.gz

I just grep'd the uncompressed file for the <Topic> start tags.

best,
christian.

* This is a rough estimate based on calculating the number of rows  
changed during the entire script execution. Since each UPDATE causes  
every row to be rewritten, there will be (N^2 - N)/2 total rows  
updated. So 8308 topics would cause a little over 155 times more row  
updates than creating 667 topics.

From sascha at umich.edu  Sun Jul 15 22:23:31 2007
From: sascha at umich.edu (Sascha Linn)
Date: Sun, 15 Jul 2007 22:23:31 -0400
Subject: [Betternestedset-talk] top down tree - any advice?
Message-ID: <20070715222331.yy3d2pjq4g04k4g8@web.mail.umich.edu>

Slightly OT maybe, but I'd like to create a view of the tree in a top 
down fashion as opposed to just an indented list. Any advice, pointers, 
links, etc. would be appreciated.

TIA,
sascha ;)

From raasdnil at gmail.com  Sun Jul 15 23:53:43 2007
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Mon, 16 Jul 2007 13:53:43 +1000
Subject: [Betternestedset-talk] top down tree - any advice?
In-Reply-To: <20070715222331.yy3d2pjq4g04k4g8@web.mail.umich.edu>
References: <20070715222331.yy3d2pjq4g04k4g8@web.mail.umich.edu>
Message-ID: <57a815bf0707152053l3dc36e2es2f633110810ce66f@mail.gmail.com>

Go have a look at the Pascal's triangle ruby quiz.  Will give you some
ideas on how to do it on a console which you could then adapt for web
pages.

Regards

Mikel

On 7/16/07, Sascha Linn <sascha at umich.edu> wrote:
> Slightly OT maybe, but I'd like to create a view of the tree in a top
> down fashion as opposed to just an indented list. Any advice, pointers,
> links, etc. would be appreciated.
>
> TIA,
> sascha ;)
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>

From raasdnil at gmail.com  Sun Jul 15 23:56:58 2007
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Mon, 16 Jul 2007 13:56:58 +1000
Subject: [Betternestedset-talk] Multiple addition of children
Message-ID: <57a815bf0707152056o413ee8aaxb6c04ada1851a470@mail.gmail.com>

Hello all,

Has anyone already handled the ability to handle an array of siblings
or children with one tree number update?

Something like:

=> children = [ child1.create, child2.create, child3.create ]
=> parent.add_children(children)

which would then renumber the tree once, instead of once for each child?

Or:

=> children.add_all_to_left_of(sibling)

?

I am going to be doing updates to a nested set... but usually an array
of updates and I was looking to see if this has been done already?

Regards

Mikel

From jc.michel at symetrie.com  Mon Jul 16 04:47:47 2007
From: jc.michel at symetrie.com (Jean-Christophe Michel)
Date: Mon, 16 Jul 2007 10:47:47 +0200
Subject: [Betternestedset-talk] Benchmarks for update_conditions.patch
In-Reply-To: <7FF42484-083A-470E-B51A-992E34861041@unit12.net>
References: <7FF42484-083A-470E-B51A-992E34861041@unit12.net>
Message-ID: <865EA640-549B-4619-9855-E7EA681B4C1F@symetrie.com>

Hi Christian,

Le 7 juil. 07 ? 23:36, Christian Niles a ?crit :
> I spent some time this afternoon developing benchmarks for the patch
> I submitted yesterday. I tested both MySQL and PostgreSQL, using
> topic names from dmoz.org. The results are pretty striking:
>
> As you can see, there is a modest improvement for MySQL, but a *huge*
> difference for PostgreSQL.

I'll try to find time to review your changes and integrate them.  
Thanks a lot for contributing !

Jean-Christophe Michel
--
symetrie.com

Better Nested Set for rails:
http://opensource.symetrie.com/trac/better_nested_set



From dontfall at gmail.com  Mon Jul 16 10:56:14 2007
From: dontfall at gmail.com (Krishna Dole)
Date: Mon, 16 Jul 2007 10:56:14 -0400
Subject: [Betternestedset-talk] Multiple addition of children
In-Reply-To: <57a815bf0707152056o413ee8aaxb6c04ada1851a470@mail.gmail.com>
References: <57a815bf0707152056o413ee8aaxb6c04ada1851a470@mail.gmail.com>
Message-ID: <8d64b97d0707160756sb8e820fo982fdcb510841ff4@mail.gmail.com>

I'm afraid I haven't. If your primary concern is performance, and you
are adding lots of children to large trees, I think you could get a
boost by adding the parent and all the children at  the far right of
the tree (fewer rows get updated), then moving the parent and children
to their proper place in a single operation. Kludgey, though.

Krishna

On 7/15/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> Hello all,
>
> Has anyone already handled the ability to handle an array of siblings
> or children with one tree number update?
>
> Something like:
>
> => children = [ child1.create, child2.create, child3.create ]
> => parent.add_children(children)
>
> which would then renumber the tree once, instead of once for each child?
>
> Or:
>
> => children.add_all_to_left_of(sibling)
>
> ?
>
> I am going to be doing updates to a nested set... but usually an array
> of updates and I was looking to see if this has been done already?
>
> Regards
>
> Mikel
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>

From raasdnil at gmail.com  Tue Jul 17 08:03:59 2007
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Tue, 17 Jul 2007 22:03:59 +1000
Subject: [Betternestedset-talk] Multiple addition of children
In-Reply-To: <8d64b97d0707160756sb8e820fo982fdcb510841ff4@mail.gmail.com>
References: <57a815bf0707152056o413ee8aaxb6c04ada1851a470@mail.gmail.com>
	<8d64b97d0707160756sb8e820fo982fdcb510841ff4@mail.gmail.com>
Message-ID: <57a815bf0707170503g5a7cbff5u754f7cec8892aeb@mail.gmail.com>

Thanks for the idea... but I came up with a change in database schema
that avoids this problem... probably for the best :)

Mikel

On 7/17/07, Krishna Dole <dontfall at gmail.com> wrote:
> I'm afraid I haven't. If your primary concern is performance, and you
> are adding lots of children to large trees, I think you could get a
> boost by adding the parent and all the children at  the far right of
> the tree (fewer rows get updated), then moving the parent and children
> to their proper place in a single operation. Kludgey, though.
>
> Krishna
>
> On 7/15/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> > Hello all,
> >
> > Has anyone already handled the ability to handle an array of siblings
> > or children with one tree number update?
> >
> > Something like:
> >
> > => children = [ child1.create, child2.create, child3.create ]
> > => parent.add_children(children)
> >
> > which would then renumber the tree once, instead of once for each child?
> >
> > Or:
> >
> > => children.add_all_to_left_of(sibling)
> >
> > ?
> >
> > I am going to be doing updates to a nested set... but usually an array
> > of updates and I was looking to see if this has been done already?
> >
> > Regards
> >
> > Mikel
> > _______________________________________________
> > Betternestedset-talk mailing list
> > Betternestedset-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/betternestedset-talk
> >
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>

From jonas at fkw.se  Mon Jul 23 11:37:23 2007
From: jonas at fkw.se (Jonas Arklint)
Date: Mon, 23 Jul 2007 17:37:23 +0200
Subject: [Betternestedset-talk] Display whole tree without requesting db for
	each node
Message-ID: <46A4CB33.4020402@fkw.se>

Hi!
I?m wondering how I display the whole tree without having to request the 
db each time I use @node.level.
Thanks!
/Jonas

From jc.michel at symetrie.com  Mon Jul 23 17:01:57 2007
From: jc.michel at symetrie.com (Jean-Christophe Michel)
Date: Mon, 23 Jul 2007 23:01:57 +0200
Subject: [Betternestedset-talk] Display whole tree without requesting db
	for each node
In-Reply-To: <46A4CB33.4020402@fkw.se>
References: <46A4CB33.4020402@fkw.se>
Message-ID: <513FF03E-562E-4023-825A-4B1507372FF1@symetrie.com>

Hi,

Le 23 juil. 07 ? 17:37, Jonas Arklint a ?crit :
> I?m wondering how I display the whole tree without having to  
> request the
> db each time I use @node.level.

You have to cache the level in db, or simply compute it in code after  
you read your tree part.

Jean-Christophe Michel
--
symetrie.com

Better Nested Set for rails:
http://opensource.symetrie.com/trac/better_nested_set



From tekin at raid.nu  Tue Jul 24 12:05:41 2007
From: tekin at raid.nu (Tekin Suleyman)
Date: Tue, 24 Jul 2007 17:05:41 +0100
Subject: [Betternestedset-talk] Display whole tree without requesting
	dbfor each node
In-Reply-To: <513FF03E-562E-4023-825A-4B1507372FF1@symetrie.com>
Message-ID: <007301c7ce0c$7bae0500$0500000a@rude10>


This is something I've wondered also as it more or less cancels out any
speed gain from getting the full set in one query. Does betternestedset
provide the hooks to cache the level? Alternatively, the parent_id could
theoretically be used to calculate levels from a full set. 



-----Original Message-----
From: betternestedset-talk-bounces at rubyforge.org
[mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of
Jean-Christophe Michel
Sent: 23 July 2007 22:02
To: betternestedset-talk at rubyforge.org
Subject: Re: [Betternestedset-talk] Display whole tree without
requesting dbfor each node


Hi,

Le 23 juil. 07 ? 17:37, Jonas Arklint a ?crit :
> I?m wondering how I display the whole tree without having to
> request the
> db each time I use @node.level.

You have to cache the level in db, or simply compute it in code after  
you read your tree part.

Jean-Christophe Michel
--
symetrie.com

Better Nested Set for rails:
http://opensource.symetrie.com/trac/better_nested_set


_______________________________________________
Betternestedset-talk mailing list Betternestedset-talk at rubyforge.org
http://rubyforge.org/mailman/listinfo/betternestedset-talk


From raasdnil at gmail.com  Tue Jul 24 19:19:38 2007
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Wed, 25 Jul 2007 09:19:38 +1000
Subject: [Betternestedset-talk] Display whole tree without requesting
	dbfor each node
In-Reply-To: <007301c7ce0c$7bae0500$0500000a@rude10>
References: <513FF03E-562E-4023-825A-4B1507372FF1@symetrie.com>
	<007301c7ce0c$7bae0500$0500000a@rude10>
Message-ID: <57a815bf0707241619i35d41e5ey599d9bff4df238b3@mail.gmail.com>

If you have this as an ongoing requirement, a "simple" solution might
be storing the level in the model itself in an after save call back.

It's a bit of a hack, but you can only move the nodes through update
calls anyway... so it might work.  Then you have it automagically as
an instance method.

Regards

Mikel

On 7/25/07, Tekin Suleyman <tekin at raid.nu> wrote:
>
> This is something I've wondered also as it more or less cancels out any
> speed gain from getting the full set in one query. Does betternestedset
> provide the hooks to cache the level? Alternatively, the parent_id could
> theoretically be used to calculate levels from a full set.
>
>
>
> -----Original Message-----
> From: betternestedset-talk-bounces at rubyforge.org
> [mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of
> Jean-Christophe Michel
> Sent: 23 July 2007 22:02
> To: betternestedset-talk at rubyforge.org
> Subject: Re: [Betternestedset-talk] Display whole tree without
> requesting dbfor each node
>
>
> Hi,
>
> Le 23 juil. 07 ? 17:37, Jonas Arklint a ?crit :
> > I?m wondering how I display the whole tree without having to
> > request the
> > db each time I use @node.level.
>
> You have to cache the level in db, or simply compute it in code after
> you read your tree part.
>
> Jean-Christophe Michel
> --
> symetrie.com
>
> Better Nested Set for rails:
> http://opensource.symetrie.com/trac/better_nested_set
>
>
> _______________________________________________
> Betternestedset-talk mailing list Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>
> _______________________________________________
> Betternestedset-talk mailing list
> Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>

From tekin at raid.nu  Thu Jul 26 08:40:23 2007
From: tekin at raid.nu (Tekin Suleyman)
Date: Thu, 26 Jul 2007 13:40:23 +0100
Subject: [Betternestedset-talk] Display whole tree without
	requestingdbfor each node
In-Reply-To: <57a815bf0707241619i35d41e5ey599d9bff4df238b3@mail.gmail.com>
Message-ID: <000601c7cf82$22dc9cd0$0500000a@rude10>

Why didn't I think of that! I'll give it a try.

-----Original Message-----
From: betternestedset-talk-bounces at rubyforge.org
[mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of Mikel
Lindsaar
Sent: 25 July 2007 00:20
To: betternestedset-talk at rubyforge.org
Subject: Re: [Betternestedset-talk] Display whole tree without
requestingdbfor each node


If you have this as an ongoing requirement, a "simple" solution might be
storing the level in the model itself in an after save call back.

It's a bit of a hack, but you can only move the nodes through update
calls anyway... so it might work.  Then you have it automagically as an
instance method.

Regards

Mikel

On 7/25/07, Tekin Suleyman <tekin at raid.nu> wrote:
>
> This is something I've wondered also as it more or less cancels out 
> any speed gain from getting the full set in one query. Does 
> betternestedset provide the hooks to cache the level? Alternatively, 
> the parent_id could theoretically be used to calculate levels from a 
> full set.
>
>
>
> -----Original Message-----
> From: betternestedset-talk-bounces at rubyforge.org
> [mailto:betternestedset-talk-bounces at rubyforge.org] On Behalf Of 
> Jean-Christophe Michel
> Sent: 23 July 2007 22:02
> To: betternestedset-talk at rubyforge.org
> Subject: Re: [Betternestedset-talk] Display whole tree without 
> requesting dbfor each node
>
>
> Hi,
>
> Le 23 juil. 07 ? 17:37, Jonas Arklint a ?crit :
> > I?m wondering how I display the whole tree without having to request

> > the db each time I use @node.level.
>
> You have to cache the level in db, or simply compute it in code after 
> you read your tree part.
>
> Jean-Christophe Michel
> --
> symetrie.com
>
> Better Nested Set for rails: 
> http://opensource.symetrie.com/trac/better_nested_set
>
>
> _______________________________________________
> Betternestedset-talk mailing list Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>
> _______________________________________________
> Betternestedset-talk mailing list Betternestedset-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/betternestedset-talk
>
_______________________________________________
Betternestedset-talk mailing list Betternestedset-talk at rubyforge.org
http://rubyforge.org/mailman/listinfo/betternestedset-talk