> > in the same file as the XML format does. Switching Leo to a Sqlite > file format certainly solves that problem, although it's a way bigger > solution scope wise than I would have contemplated. Being familiar > with DBs and SQL I'm not opposed to it myself, but are we really > discussing dropping Leo's XML format here? People more familiar with > XML than SQL might find that disagreeable. > > Yes, we are discussing dropping Leo's XML format. It is continuation of the discussion since 9 years ago. IMO XML has no real advantage over sqlite. Sqlite format easily crosses platform/language boundaries, it is stable, widely spread, (advertised as small, fast and reliable choose any three). It is designed to be safe. What would happen if power is out while writing XML file to drive - file gets corrupted. Sqlite has protection against this situation if power is lost while committing to db file. The only thing that is lost is just last transaction. Db file remains readable and its content is exactly the same as before last transaction started. Currently Leo has many (countless) files on disc for its normal operation. With sqlite almost all those files can be stored in one or two db files. If we are to believe benchmarks on sqlite, it is faster than filesystem when files are under 100k. (See <https://www.sqlite.org/intern-v-extern-blob.html>).
The only advantage of XML is that it is human readable, but I really doubt that it can add any benefit to user. I would argue that in fact sqlite file is more human readable than XML if one uses any of many available tools for reading/manipulating sqlite db files. It is much easier to understand and change something in sqlite representation of Leo document than it is in XML version. > > If we do drop XML, I suggest making a stand alone XML -> DB converter > rather than maintaining XML support in Leo's core. Leo can always > invoke the converter as needed (it would be part of the Leo > distribution), but it would be a good chance to trim code from the core. > > Yes that is good idea. I have created small script/module leo.extrenal.sax2db which takes as argument path to .leo document and creates .db version of it in the same folder. > Also we need to think a bit about the DB design - I think Vitalije you > mentioned using lists of gnxs in a single field in a record to > represent children... should consider that approach vs. something more > relational. > I agree it is not normalized representation. But in current implementation Leo just stores every vnode in db file, and few additional information like position and dimensions of app window and md5 hashes for every external file related to Leo outline and currently selected position. When opening db file Leo reads all that data at once and recreates its runtime data structures. It doesn't use connection at all in the rest of code. This is good enough for now, but it certainly can and should be improved if Leo starts to rely more on db in the rest of its code. > Also I think we'd be missing a big opportunity if we don't have a clean > break between the DB reading code and the DB connection, i.e. support > the possibility of using DBs other than sqlite. If the code's using > the Python DB API (PEP 249) then we're probably already in good shape > here, just saying we should isolate any sqlite specific code. Here I'm > talking about dropping the XML format, not just the settings stuff. > > AFAIK sqlite3 module in Python standard distribution is compliant to Python DB API. Maybe the only thing different is that in sqlite3 connection implements mehtods of cursor objects so it is not needed to create cursor to invoke some method. If we decide to switch to some other DB library it would be trivial to create wrapper for its variant of connection (to keep similar with sqlite3). Nothing special about sqlite is used. > Exciting times :-) > > Yes, they are ! -- 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
