Re: sqlite-format and settings - ideas

Ohh I see. I was thinking because XML was so cluttered that the problem laid there and makes not only difficult to read it, but to diff it In the case of STON the serializer enumerates the objects and use pointers to them using ordinal numbers (like @1 or @20), so moving children is mostly

Re: sqlite-format and settings - ideas

On Sun, Jul 9, 2017 at 11:10 AM, Offray Vladimir Luna Cárdenas < off...@riseup.net> wrote: > Some fairly simple changes like sorting siblings can give false impression >> of massive changes when in fact there is no big difference in code. >> > > Yes. This is truly annoying. > > That's why of us

Re: sqlite-format and settings - ideas

Hi, On 09/07/17 09:06, Edward K. Ream wrote: > On Sunday, July 9, 2017 at 7:44:06 AM UTC-5, vitalije wrote: > > To my surprise, the resulting diff is even worst than I > thought it would be: > >

Re: sqlite-format and settings - ideas

I'm following this thread and new wave of ideas for leo with great attention. I really like the goal of making leo a more interactive platform for keeping/editing knowledge bases... Great job everybody! Just my 2 cents: Maybe sqllite is just a tool for a greater purpose, a step toward a greater

Re: sqlite-format and settings - ideas

On Sunday, July 9, 2017 at 7:44:06 AM UTC-5, vitalije wrote: > > To my surprise, the resulting diff is even worst than I thought it would >> be: >> https://github.com/xgid/leo.db-vcs-tests/commit/5648c4ea02c9e1f47efe86ec990fc9aff6554c11?diff=unified >> > > Well I am not satisfied with xml diffs

Re: sqlite-format and settings - ideas

On Sunday, July 9, 2017 at 4:00:53 AM UTC-5, xgid wrote: > > I also made a minimal research of the matter before my posts, with the > following several search terms: > >- sqlite binary git >- sqlite git diff >- sqlite git howto store > > and came across the same links and some

Re: sqlite-format and settings - ideas

> > To my surprise, the resulting diff is even worst than I thought it would > be: > https://github.com/xgid/leo.db-vcs-tests/commit/5648c4ea02c9e1f47efe86ec990fc9aff6554c11?diff=unified > Well I am not satisfied with xml diffs either. I believe that it can be done by exporting only those

Re: sqlite-format and settings - ideas

On Sat, Jul 8, 2017 at 10:43 AM, Chris George > wrote: Here is one approach to using sqlite with git. https://ongardie.net/blog/sqlite-in-git/ ​Thanks for this. And here is a stack

Re: sqlite-format and settings - ideas

On Sat, Jul 8, 2017 at 10:43 AM, Chris George wrote: > Here is one approach to using sqlite with git. > > https://ongardie.net/blog/sqlite-in-git/ > ​Thanks for this. And here is a stack overflow response . ​All this research

Re: sqlite-format and settings - ideas

Here is one approach to using sqlite with git. https://ongardie.net/blog/sqlite-in-git/ Chris On Sat, Jul 8, 2017 at 2:16 AM, Xavier G. Domingo wrote: > From Offray: > > as I understand Sqlite storate will be used only for settings > > and from Terry: > > I don't think

Re: sqlite-format and settings - ideas

From Offray: as I understand Sqlite storate will be used only for settings and from Terry: I don't think we've considered the impact of switching to a binary format *That's an important point that was not so clear until now! *At least not for me considering that Vitalije said the following at

Re: sqlite-format and settings - ideas

Uau, that is a community reaction! *Thanks to all for your comments*. I'll try to answer them all as soon as I can... but probably not until late tonight. Let's keep up the good work! Xavier -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To

Re: sqlite-format and settings - ideas

On Fri, Jul 7, 2017 at 10:15 AM, Terry Brown wrote: I'm not sure but I suspect your emphasis is intended to be humorous. > Or at least to underscore an important point by coming at it > ​ ​ > sideways :-) > ​Thanks for all your comments. I prefer exploration ​ ​to

Re: sqlite-format and settings - ideas

> > > I don't agree. The concurrency problems will, but the problems to have > Sqlite files under git are here right now > : > > *In short, you’ll probably be unhappy trying to keep a database versioned >> using a source control system.* > > > There

Re: sqlite-format and settings - ideas

On Fri, 7 Jul 2017 10:10:27 -0500 Offray Vladimir Luna Cárdenas wrote: > Yes, theoretically. In practice Sqlite over XML have proved better > response time in loading and querying when two representation of the > same data are available, at least in my experience. But see my

Re: sqlite-format and settings - ideas

On Thursday, July 6, 2017 at 10:58:29 AM UTC-3, Terry Brown wrote: > I think you're right in that another option would be to use something > like the leosax module that reads Leo outlines into a simple dict/list > representation in a fraction of the time Leo usually takes to load an >

Re: sqlite-format and settings - ideas

On Fri, 7 Jul 2017 07:39:20 -0700 (PDT) xgid wrote: > > Well, discussion shows that we're agree about the worthiness of > > this exploration. > > Yes, we do! > > > I think that Sqlite limitations you mention will be far to reach > > compared with XML limitations > > I

Re: sqlite-format and settings - ideas

Hi, Answer in inline comments, below. On 07/07/17 09:39, xgid wrote: > > Well, discussion shows that we're agree about the worthiness of > this exploration. > > > Yes, we do! > > > I think that Sqlite limitations you mention will be far to reach > compared with XML limitations

Re: sqlite-format and settings - ideas

> Well, discussion shows that we're agree about the worthiness of this > exploration. > Yes, we do! > I think that Sqlite limitations you mention will be far to reach compared > with XML limitations > I don't agree. The concurrency problems will, but the problems to have Sqlite files

Re: sqlite-format and settings - ideas

Xavier, Well, discussion shows that we're agree about the worthiness of this exploration. I think that Sqlite limitations you mention will be far to reach compared with XML limitations, which are now starting to show now, like reloading settings time. I would try to take this first step forward

Re: sqlite-format and settings - ideas

> What I'm suggesting is that we should try to take advantage of this work > to make the right architectural changes to Leo so it can easily handle > *any** storage backend*. > > In the same way, I think we should try to have an abstraction layer from > the underlying SCM, so it can be git

Re: sqlite-format and settings - ideas

Ville on this counts with my "moral" support (because my technical capability is departing from Leo and Python to Grafoscopio and Pharo) and this is a worthy exploration. Advocating for a simpler Leo format has been in this forum since several years ago (YAML, JSON, etc have been in our

Re: sqlite-format and settings - ideas

​ On Thu, Jul 6, 2017 at 12:53 PM, xgid wro ​te​ > But I really think we should treat each of this issues as they deserve > from good software engineers: as separate "Projects" or "Feature requests", > with clear and detailed Requirements and Use Cases for each one and

Re: sqlite-format and settings - ideas

On Thursday, July 6, 2017 at 10:42:24 AM UTC-3, Josef wrote: > > Just my 2 cents worth: > > you can't merge sqlite databases easily - git does not know how to do > that. However, most of the time merging XML files will just do the right > thing, and if not, you can look at the human readable

Re: sqlite-format and settings - ideas

Thanks Vitalije for your detailed explanation. I see that you have a clear picture of the road to go, I was just trying to clarify the ideas for all so we can take the best architectural decisions. I wish you good luck when crossing Settingsville. We all need your success in that heroic deed!

Re: sqlite-format and settings - ideas

On Sun, Jul 2, 2017 at 11:00 AM, vitalije wrote: > As my experiments proved it is possible to collect and transfer all > settings from traditional .leo settings files into sqlite database. > ​I'm not sure whether this has been discussed. No matter what form outlines take,

Re: sqlite-format and settings - ideas

Hi, On 06/07/17 08:42, Josef wrote: > Just my 2 cents worth: > > you can't merge sqlite databases easily - git does not know how to do > that. However, most of the time merging XML files will just do the > right thing, and if not, you can look at the human readable diff to > figure out what went

Re: sqlite-format and settings - ideas

Hi, On 06/07/17 01:06, vitalije wrote: [...] > > As you can see even if I work towards adoption of a new format for Leo > documents, some results of those endeavors may be found useful even > without changing format. > > I don't see why those settings affecting those objects can be >

Re: sqlite-format and settings - ideas

On Thu, 6 Jul 2017 06:42:24 -0700 (PDT) Josef wrote: > Just my 2 cents worth: > > you can't merge sqlite databases easily - git does not know how to do > that. However, most of the time merging XML files will just do the > right thing, and if not, you can look at the human

Re: sqlite-format and settings - ideas

On Thu, 6 Jul 2017 00:49:52 -0300 "Xavier G. Domingo" wrote: > Thanks for the thorough explanation. But you don't need a GUI app to > read an XML, as you don't need a GUI app to read from an SQLite file. > I understand that you need to read all the settings files to be able

Re: sqlite-format and settings - ideas

Just my 2 cents worth: you can't merge sqlite databases easily - git does not know how to do that. However, most of the time merging XML files will just do the right thing, and if not, you can look at the human readable diff to figure out what went wrong. - Josef -- You received this

Re: sqlite-format and settings - ideas

> > > Thanks for the thorough explanation. But you don't need a GUI app to > read an XML, as you don't need a GUI app to read from an SQLite file. I > understand that you need to read all the settings files to be able to > fully initialize Leo, but you don't need (or should not need) al Leo's

Re: sqlite-format and settings - ideas

I mean that it should be possible to have also a real-time settings edition experience by editing Leo outlines, shouldn't it? ​It's not that easy. Many settings affect the creation of objects.​ Sure, but which objects? I mean: I don't see why those settings affecting those objects

Re: sqlite-format and settings - ideas

I don't know any other way. Perhaps there is another and maybe even better way, but I can't imagine it. At present Leo uses same code to read user document and to read settings files. One of the settings that is very important is enabled_plugins. It can be defined in leoSettings.leo, in

Re: sqlite-format and settings - ideas

On Wed, Jul 5, 2017 at 2:35 PM, vitalije wrote: > Hi Xavier, > > >> ... it takes me to what could be a naive question from my part but, is it >> really impossible to simplify the init code without requiring the switch to >> sqlite-based settings? It seems strange to me that

Re: sqlite-format and settings - ideas

On Wed, Jul 5, 2017 at 2:09 PM, Xavier G. Domingo wrote: It seems strange to me that the access to those settings cannot be made *independent > of the underlying source* by the use of an intermediate abstraction layer > or proxy > ​...I mean that it should be possible to

Re: sqlite-format and settings - ideas

Hi Xavier, > ... it takes me to what could be a naive question from my part but, is it > really impossible to simplify the init code without requiring the switch to > sqlite-based settings? It seems strange to me that the access to those > settings cannot be made *independent of the

Re: sqlite-format and settings - ideas

On Wed, Jul 5, 2017 at 11:37 AM, vitalije wrote: > >> ​I do not understand​ why you are concerned about settings. This seems >> like a natural migration path: >> >> I am not so much concerned with the settings as I am concerned with > Leo's init code. I have a strong

Re: sqlite-format and settings - ideas

Hi Vitalije, I'm following your work in the sqlite-leo branch with great interest. Congratulations for this great idea and endeavour! Some of your ideas are being quite inspiring for me. Regarding your recent comment about simplifying Leo's init code: However, as I have stated in README of

Re: sqlite-format and settings - ideas

> > > ​I do not understand​ why you are concerned about settings. This seems > like a natural migration path: > > I am not so much concerned with the settings as I am concerned with Leo's init code. I have a strong feeling that the way Leo handles settings at present complicates init code.

Re: sqlite-format and settings - ideas

On Wed, Jul 5, 2017 at 5:38 AM, vitalije wrote: I have made a function which would examine outline and collect all settings > from it and store the result in db table. > ​I do not understand​ why you are concerned about settings. This seems like a natural migration path: -

Re: sqlite-format and settings - ideas

On Wed, Jul 5, 2017 at 4:30 AM, vitalije wrote: > Yes, we are discussing dropping Leo's XML format. > ​Imo, we are discussing adding support for .leo.db files, not removing support for .leo files. ​ > The only advantage of XML is that it is human readable > ​That can be

Re: sqlite-format and settings - ideas

Still looking in leoConfig parser methods. In Leo documentation there is no reference about at-outlinedata and I am not sure how they are supposed to work, but one thing seems like a bug to me. Shouldn't method doOutlineData return 'skip'? If I am not mistaken at-outlinedata is supposed to have

Re: sqlite-format and settings - ideas

Well this was a nice surprise! When I looked in leo.core.leoConfig.ParserBaseClass and its methods I have found that at-if is not supported! Instead at-ifenv is supported. It gives a chance for collecting all settings in a table with two additional columns one for host condition and the other

Re: sqlite-format and settings - ideas

I tried to extend sax2db (leo.externals.sax2db) script to collect settings data from outline and then I have realized that it would not bring any benefit. I have made a function which would examine outline and collect all settings from it and store the result in db table. However, Leo currently

Re: sqlite-format and settings - ideas

> > 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

Re: sqlite-format and settings - ideas

On Sun, 2 Jul 2017 13:44:23 -0700 (PDT) vitalije 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 >

Re: sqlite-format and settings - ideas

On Sun, Jul 2, 2017 at 2:42 PM, Terry Brown wrote: On Sun, 2 Jul 2017 09:00:22 -0700 (PDT) > vitalije wrote: > > > A problem can arise when user changes any of relevant settings files: > > some .leo.db files can have outdated settings embedded. > >

Re: sqlite-format and settings - ideas

> > 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

Re: sqlite-format and settings - ideas

On Sun, 2 Jul 2017 09:00:22 -0700 (PDT) vitalije wrote: > A problem can arise when user changes any of relevant settings files: > some .leo.db files can have outdated settings embedded. The arrangement that springs to mind for me is: The default settings, currently

Re: sqlite-format and settings - ideas

And once more, I am imagining web browser UI for editing settings once they are in stable well known locations. But one step at the time. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails

sqlite-format and settings - ideas

As my experiments proved it is possible to collect and transfer all settings from traditional .leo settings files into sqlite database. If we use sqlite as file format for outline data it is trivial to keep the collected settings in the same file. A problem can arise when user changes any