This schema (with NODES and EDGES) is sufficient to efficiently store leo doc structure:
https://gist.github.com/vivainio/1493084 On Fri, Mar 22, 2013 at 1:37 AM, David McNab <[email protected]> wrote: > All good thoughts, Don. I'm a fan of diff-able text formats myself. > > I'm wondering if a good first step might be a generic "save/load" > interface layer with several pluggable backends, such as: > > - Single file storage - this would buffer up all the saved nodes, > amalgamate them and write them out as a single .xml file. Oh yes, the > familiar .leo file format :P > - *sql implementation - this would have MySQL, PostgreSQL and SQLite > variants - saving one node per row > - Key/value for Berkeley DB and similar > - NoSQL - for those who can be bothered > - JSONRPC/XML-RPC implementation - saving to/loading from a central > server > > For SQL database storage, the schema doesn't have to be difficult. The > main quirk would be a many to many related join between parent and child, > which would support clones by allowing any given node to have multiple > parents. > > Cheers > David > > On Fri, Mar 22, 2013 at 12:18 PM, Don Dwiggins > <[email protected]>wrote: > >> On 3/21/13 7:59 AM, Ville M. Vainio wrote: >> >> DB like storage for leo documents comes up every 6 months. Technically, >> it makes sense in many ways, but it's about payback vs. implementation work. >> >> >> Some quick thoughts on this: >> >> - I recently converted a server that used XMLRPC, to use JSONRPC. >> Some testing revealed that it improved the speed of processing large >> message by a few orders of magnitude. Even if Leo were to stay with a >> text-based format, it might be worth investigating a "lighter" format than >> XML. (There's a quote floating around the net: "Some people, when >> confronted with a problem, think 'I know, I'll use XML.' Now they have two >> problems.") That said, I'm a total newbie to Leo, and offer this just in >> case it rings a bell... >> >> - One advantage of a text format: it can easily be put under >> revision control, and the differences between revisions easily reviewed. >> A >> "versioned" DB format is possible, of course, and might even have been >> implemented; still, it's a consideration. >> >> - The Chandler project (http://chandlerproject.org/) has been going >> for many years, and is based on a storage format of their own designing, >> intended to be used for storing emails, calendars, tasks, .... It might >> repay some investigation. >> >> - For multi-user situations, a Leo-specific server, possibly >> implemented in Twisted, might be worth considering. >> >> >> >> Again, FWIW, >> Don Dwiggins >> Emacs user looking to transition to Leo... >> >> -- >> You received this message because you are subscribed to the Google Groups >> "leo-editor" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/leo-editor?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/leo-editor?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
