Chris Anderson wrote:
On Tue, Mar 17, 2009 at 4:07 PM, Daniel Friesen <[email protected]> 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)
