On Tue, Dec 20, 2011 at 12:24 PM, Seth Johnson <seth.p.john...@gmail.com> wrote: > On Tue, Dec 20, 2011 at 12:58 PM, Kent Tenney <kten...@gmail.com> wrote: >>> >>> In my architecture, nodes point up to their parents. >> >> How do you maintain sibling order? >> >> I've been settling on node "addresses" in metadata, >> it's a list of child indexes. It provides each node with a >> self contained description of where it lives, which I like. >> I haven't come across a more succinct way to do that. > > > A counter field that you add to an index on the parent key field. > > So you search for the record that has no parent key -- that's the top. > > Then you search for that record's key in the parent key index -- that > will have its children in sibling order. > > And so forth. > > I don't do SQL searches, which would probably make this slow, just a > local navigation algorithm on the index. > > You seem to have hit on something similar to my scheme with your self > contained descriptions of where nodes live. The records I'm speaking > of are just fields holding keys in that uniform structure I speak of, > so each record holds the context -- plus the particular "node" key, > which I call a link. > > "Nodes" are actually also metadata -- you don't really get "data data" > until you seek attribute values.
It sounds like the moral equivalent of a linked list. The "address" approach I've been leaning towards feels more robust / useful, but I haven't implemented with it, so I really don't know. It seems like what you describe is closer to the "node and edge" world view that graph software uses. In the web framework world there is a similiar dichotomy, mapping urls to content vs. traversing url paths. > > > Seth > > > >> You access all >>> the nodes for a context, and they come with pointers to their parents, >>> and maybe the server can traverse that and give them to you in outline >>> order, or you can do that locally once the server just provides the >>> relevant nodes. >>> >>> >>>> At present, I don't see a good way forward. That's ok: I've got bugs to >>>> fix ;-) >>> >>> >>> :-) >>> >>> >>> Seth >>> >>> >>>> Edward >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "leo-editor" group. >>>> To post to this group, send email to leo-editor@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> leo-editor+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/leo-editor?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "leo-editor" group. >>> To post to this group, send email to leo-editor@googlegroups.com. >>> To unsubscribe from this group, send email to >>> leo-editor+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/leo-editor?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "leo-editor" group. >> To post to this group, send email to leo-editor@googlegroups.com. >> To unsubscribe from this group, send email to >> leo-editor+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/leo-editor?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To post to this group, send email to leo-editor@googlegroups.com. > To unsubscribe from this group, send email to > leo-editor+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/leo-editor?hl=en. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
