On Thu, Dec 29, 2011 at 5:13 AM, Ville M. Vainio <[email protected]> wrote: > On Thu, Dec 29, 2011 at 11:43 AM, Seth Johnson <[email protected]> > wrote: > >> No reason you can't query a flat file; just no joins involved, is all. > > Yeah, and you would have to implement sql engine yourself ;-).
Huh? Why? If you're talking about tree traversal, I've addressed that elsewhere in this thread. But querying a flat table in SQL . . . what are you going on about? >>> Pointing at parent doesn't work in Leo because of clones. This is why >>> Leo outline is more of a DAG than a simple tree, a node can have >>> multiple parents if it's cloned somewhere in the outline. >> >> >> That it's directed doesn't mean you can't do clones with parent >> pointers -- except that within the model of a graph scheme one tends >> to think of nodes like objects, rather than modeling "nodes" as >> metadata for the values associated with them. (And the convention is >> to point toward children, I assume.) There's no reason you can't have >> the same key value designating the same "node" in more than one place >> in the outline, pointing up to a different parent in each case; the >> values associated with that key value aren't "contained" in it like a >> node -- they're just *relevant* everywhere that "node" is used. > > Not sure whether I'm following you, but if you want to have "parent > pointer + child index" representation, you would re-introduce the > already killed concept of vnodes and tnodes to support clones. > > Can you paste your schema here, since I may be misunderstanding > something? What I have is just a bog standard graph representation I > found on the internet, as I'm averse to inventing solutions to > problems for which simple solution already exists. Your aversion would likely stand in the way of appreciating it then. I would have to get it off an old hard drive. I wonder if I zipped it up and put it online somewhere. I will dig out an SQL tool and create the main link table, link attribute, and link attribute value tables, from memory. The indexes are done in dBASE, and are rather unique so I won't reconstruct them. This is better anyway, to describe the system gradually. However, I've drawn the structure of the main "node" outline table above in this thread. Attributes and their values are stored in separate tables with the same key values, now including the "node's" key (and the attribute and the attribute value). Seth > Separate edge section was suggested for next gen .leo xml file format > as well - it would allow representing soft links (that can be cyclic!) > directly in the graph section as first class citizens, instead of the > uA solution that is used now. > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
