That all depends on a number of factors I think. If said tree didn't have any logic to handle these partial "ajax" requests then I would have to agree about the performance problem..
I do know however that the latest version of the tacos tree ~does~ take into account the fact that it is involved in a partial request, and so doesn't cause any unneeded DB hits. The content provider implementation that ~you~ provide does have to take the partial request into account as well, otherwise all ajax requests would result in you re-querying the entire result set that originally produced the tree... The content provider that I personally use along with the tacos tree uses knowledge of the partial request, as well as parameters set on the page when the nodes are selected to ONLY query the DB for the rows required to render the request. Of course most of this was made a lot easier via the use of hibernate, but normal JDBC operations should be able to do it just as easily. Where do you see the performance hit? If you are speaking of the LiveGrid behaviour, I'd have to agree with you. At least in the current incarnation that rico provides it in, which I don't personally agree with. The paging mechanism makes more sense to me, and again I'd have to ask where you see the performance breakdown? The "set" should be faster by many orders of magnitude when adding additional parameters to your sql query, like a range limiter of some sort. Unless the DB in question isn't properly indexed, or the SQL being used to represent the tree is inherently flawed I don't see the issue. I am genuinely interested in what problems you forsee. If you could be more specific it would help me rationalize a response. jesse On 9/8/05, Konstantin Ignatyev <[EMAIL PROTECTED]> wrote: > > Would the 'nested set' work well or not does not > depend on size, but on 'stability' of the tree. > > For 'stable' tree (updated nightly) nested set model > does excellent job no matter what the size is. And of > course I mean working hierarchical queries, not simple > 'lazy' navigation. > > > --- Karthik Abram <[EMAIL PROTECTED]> wrote: > > > > > > > This would work for small trees, not "really large > > trees" as requested in > > the email. For insertions and moves, you are good as > > long as you can avoid > > the "step" problem, however, when you do hit it, you > > have to adjust half the > > nodes. It gives particularly poor performance when > > you have concurrent > > operations. > > > > -----Original Message----- > > From: Konstantin Ignatyev > > [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 08, 2005 4:04 PM > > To: Tapestry users > > Subject: RE: Presenting really large trees > > > > > > Not really. Left and Right values can be incremented > > in 'steps' and depending on the step size we could > > insert many nodes without the need to recalculate > > entire tree. > > > > Deletion is always cheap - no recalculation > > required. > > > > > > --- Karthik Abram <[EMAIL PROTECTED]> wrote: > > > > > > > > Thats a terrible model for a dynamic tree > > though... > > > > > > -----Original Message----- > > > From: Konstantin Ignatyev > > > [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, September 08, 2005 3:37 PM > > > To: Tapestry users; [EMAIL PROTECTED] > > > Subject: Re: Presenting really large trees > > > > > > > > > Not necessarily about UI, but 'nested set' tree > > > representation works extremely well and simplifies > > a > > > lot of typical hierarchical queries > > > http://www.dbmsmag.com/9603d06.html > > > > > > I recomment Joe's book 'SQL for Smarties' > > > > > > --- Tapestry Stuff <[EMAIL PROTECTED]> > > wrote: > > > > > > > Hi, wondering if anyone has come up with a nicer > > > way > > > > to present LARGE sets > > > > of hierarchical data. Trees are fine but the > > large > > > > set makes the tree > > > > unwieldy. We have been using tacos tree for a > > long > > > > time but now the set has > > > > grown so large as to cause us grief with page > > > layout > > > > and looong db queries. > > > > I think that persisting the tree is out of the > > > > question as the set is too > > > > large. > > > > > > > > Any ideas? > > > > > > > > -- > > > > Nick > > > > > > > > > > > > > Konstantin Ignatyev > > > > > > > > > > > > > > > PS: If this is a typical day on planet earth, > > humans > > > will add fifteen > > > million tons of carbon to the atmosphere, destroy > > > 115 square miles of > > > tropical rainforest, create seventy-two miles of > > > desert, eliminate between > > > forty to one hundred species, erode seventy-one > > > million tons of topsoil, add > > > 2,700 tons of CFCs to the stratosphere, and > > increase > > > their population by > > > 263,000 > > > > > > Bowers, C.A. The Culture of Denial: Why the > > > Environmental Movement Needs a > > > Strategy for Reforming Universities and Public > > > Schools. New York: State > > > University of New York Press, 1997: (4) (5) > > (p.206) > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
