Chris Anderson wrote: > On Tue, Mar 17, 2009 at 4:07 PM, Daniel Friesen wrote: > >> Chris Anderson wrote: >>>> ... >>>> >>>> >>> Taking this approach would probably require that you store the full >>> path(s) to the widget on the widget document itself. This isn't so bad >>> but does complicate changing only a parent node say, halfway up the >>> tree, as you have to touch all it's subnodes. >>> >>> >> Not really possible. There is no full path to the widget in the document. >> Quite simply because widgets don't belong to a document (I have limited it >> so that widgets can't cross sites) but a widget can belong to multiple >> parent widgets and as a result can belong to multiple pages. >> The ability to put the same Widgets on multiple pages is essential to the >> app we're building so it can't really be worked around. >> > > This is possible, as long as you are willing to eat up a fair amount > of disk space caching *all possible* paths to the jit. I guess I'm > essentially talking about running your "walk" function and then > memoizing the results of it [an array of paths] on the jit document > itself. This should be possible as long as the graph of nested jits is > acyclic. > > The queries from such a view would be pretty clean. For a given root > page-id you'd be able to pull in all and only the jits on that page > (sorted according to their nesting order) in a single request. > Ok, though I guess it's just kind of annoying that I have to store inverse data and a bit of hierarchy all in the document and each and every time I change the hierarchy a bit I have to go through every last jit relevant to both the old and new structure and update it, when all I'm really trying to do is move a simple algorithm (walking) into the database to avoid the overhead of communication between the database and application when not one bit necessary. ~Daniel Friesen (Dantman, Nadir-Seen-Fire)