Bob, How do you update a model using this method. It seems to only work on "create" callbacks. On Friday, April 07, 2006, at 11:08 AM, Bob Silva wrote: >Hi Chris, > >This doesn't really belong on core but I can point you to an alternative >solution to prevent the FULL table update. While your solution is >imaginative, the fact that it doesn't scale sinks the boat. > >http://www.railtie.net/articles/2006/03/31/ >implement-acts_as_threaded-withou >t-a-plugin > >You can also make use of the :scope parameter to make localized updates. > >Bob Silva >http://www.railtie.net/ > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:rails-core- >> [EMAIL PROTECTED] On Behalf Of Chris T >> Sent: Thursday, April 06, 2006 2:28 AM >> To: rails-core@lists.rubyonrails.org >> Subject: [Rails-core] Acts_as_nested query >> >> Posted this originally to main rails list, but prob more appropriate for >> rails-core. Feel free to shoot me down in flames. I'm pretty much a noob >> here, and also in db theory. >> >> Wondering about using the acts_as_nested for a model but concerned about >> the performance overhead of having to rewrite the table each time and >> entry is added or removed(and locking it while it's happening or risking >> data integrity probs). Wasn't really familiar with the structure so did >> a little reading up on it, and one solution to this seems to spreading >> the table out, so that [using the table in the API as an example], >> instead of: >> >> ID | PARENT | LEFT | RIGHT | DATA >> 1 | 0 | 1 | 14 | root >> 2 | 1 | 2 | 7 | Child 1 >> 3 | 2 | 3 | 4 | Child 1.1 >> 4 | 2 | 5 | 6 | Child 1.2 >> 5 | 1 | 8 | 13 | Child 2 >> 6 | 5 | 9 | 10 | Child 2.1 >> 7 | 5 | 11 | 12 | Child 2.2 >> >> you would do this: >> >> ID | PARENT | LEFT | RIGHT | DATA >> 1 | 0 | 10 | 140 | root >> 2 | 1 | 20 | 70 | Child 1 >> 3 | 2 | 30 | 40 | Child 1.1 >> 4 | 2 | 50 | 60 | Child 1.2 >> 5 | 1 | 80 | 130 | Child 2 >> 6 | 5 | 90 | 100 | Child 2.1 >> 7 | 5 | 110 | 120 | Child 2.2 >> >> Then if you added a new entry 8, which was a child of 2, for example, >> you could give it a lft of 121 and a rgt of 122, meaning no full-table >> re-write. Of course this fails down eventually and does require at least >> a partial table rewrite (and you'd prob want to do a multiple of more >> than 10 on the entries to begin with), but it would certainly cut down >> the probs. Anybody got any comments? There's probably a good reason why >> the AR implementation takes the full-rewrite approach, and I'm pretty >> much a noob (not a programming background) so feel free to shoot me down >> in flames. >> >> The new table would look like: >> >> ID | PARENT | LEFT | RIGHT | DATA >> 1 | 0 | 10 | 140 | root >> 2 | 1 | 20 | 70 | Child 1 >> 3 | 2 | 30 | 40 | Child 1.1 >> 4 | 2 | 50 | 60 | Child 1.2 >> 5 | 1 | 80 | 130 | Child 2 >> 6 | 5 | 90 | 100 | Child 2.1 >> 7 | 5 | 110 | 120 | Child 2.2 >> 8 | 5 | 121 | 122 | Child 2.3 >> >> Cheers >> Chris T >> >> _______________________________________________ >> Rails-core mailing list >> Rails-core@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-core > >_______________________________________________ >Rails-core mailing list >Rails-core@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-core
-- Posted with http://DevLists.com. Sign up and save your mailbox. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
