On Sun, 2 Jul 2017 13:44:23 -0700 (PDT) vitalije <[email protected]> wrote:
> > > > > I don't see a clear reason for all settings to be in each Leo > > outline, I think users are used to personal and default settings > > that are separate from file specific settings. > > > > Cheers -Terry > > > > That is what I thought as first solution. The reason I had in mind > for the second variant was that we can possibly reduce search trouble > for all folders and files to check. If everything is inside database > file the only sacrifice we have to make is to allow some documents to > have outdated settings. In return we get the ability to have c.config > working in fewer steps. Perhaps it is not so important as I thought > it would be. OTOH, maybe it could have some advantages. For example > it maybe useful sometimes when sharing Leo documents to share them > along with all their settings. If shared file relies on some settings > from myLeoSettings.leo, then it could happen that when opened on some > other machine it won't look/work the same. The more I think about it the more I think having all settings in each Leo file is a counter productive break with the existing distributed / personal / local system: distributed: the settings distributed with Leo in leoSettings.leo personal: user's settings in myLeoSettings.leo local: settings in the particular Leo file If the setting's in the current Leo file, it takes precedence, easy. If it's in myLeoSettings.leo, I don't expect it to be transferred to someone else, or even another system of mine, with each Leo file. For example my myLeoSettings.leo sets a dark theme that uses icons that others may not have. Finally if neither the local Leo file or myLeoSettings.leo specifies a value for a setting, I expect the default to come from the version of leoSettings.leo that I have installed, not the version that was on the system that originated the Leo file. It seems the concern is about performance, which should never be a concern until it manifests as a problem. https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize So DB based settings code would be something like: # one time per outline code connections = [] if leoSettings DB exists: connections.insert(0, connection to leoSettings DB) if myLeoSettings DB exists: connections.insert(0, connection to myLeoSettings DB) if settings exist in local Leo file: connections.insert(0, connection to local Leo file DB) # c.config() call for connection in connections: result = query connection for setting if result: return setting value else: setting not found I'd see if that's fast enough before trying something else. > In case we have parallel sqlite and xml versions of settings, we have > to sync them and to check if user edited one and not the other. Also I think we should avoid this situation. I don't really see any benefits in having both systems in parallel. It certainly doesn't simplify code, and won't simplify user experience unless one (presumably the XML version) is "kept secret" from users. So I think the potential for greatly simplifying settings code with DBs remains. The tricky part is still how to keep file specific settings 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. Or are there other ways to use DBs for settings without such a major change? One way would be the side by side .leo XML outline and .sqlite settings file, a regression in that both files must be moved around together, but much less of a major change, and it would allow the benefits of DB based settings to be fully evaluated without the concurrent upheaval of an XML -> DB switch. 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. 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. 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. Exciting times :-) Cheers -Terry > we have to keep all present code in case there are no sqlite versions > of files. We won't be able to remove anything in init code and no > simplification that I hoped for. The second solution was in essence > plan for migration to new file format and then simplifying by > eliminating unnecessary blocks of code. > > Vitalije > -- 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.
