I must admit I'm not using new-auto, embarrassing after all my fussing. - the @persistence tree got huge, cluttered versioning - turned out my back end storage needed to implement it's own keys for @auto nodes - if I have @auto myfile.py in multiple Leo files, they need the same keys
The back end db uses gnx for native nodes, concats the headlines for ephemerals: like <host.file.class.method> Sorry, presumably others are benefiting from all the work that went into @persistence. Regarding gnx/uuid, I'm an outlier in never seeing sentinels, so I should be quiet. On Tue, Oct 21, 2014 at 7:29 PM, Edward K. Ream <[email protected]> wrote: > Terry congratulated me on fixing #76 erroneous clone markers in @auto trees. > The celebrations are premature. > > It's easy to see at least one flaw in the present gnx allocation code: the > post-pass calculates ni.lastIndex after reading all external files > **including @auto nodes**. > > But suppose the @auto node contains a new node (a node created outside of > Leo). The @auto read code will *immediately* allocate a gnx for the new > node. This happens before the post-pass runs, so the newly allocated gnx > could clash with a previously allocated gnx! > > Yes, this can only happen if the present invocation of Leo clashes with a > previous invocation of Leo. (Two invocations of Leo **clash** if both are > based on the same timestamp.) We all now agree that clashes *do* happen. > The post-pass was supposed to be a workaround. But we shall soon see that it > isn't. > > My first thought was to delay the allocation of new gnx's until after the > postpass. Like this: > > 1. ni.getNewIndex would allocate None as the gnx if it is called before the > post-pass. In that case, getNewIndex would add the vnode with the dummy gnx > to a global list. > > 2. After the post-pass, all nodes on this list would get a proper, safe, gnx > based on the updated ni.lastIndex. > > But this is all delusion! Consider these itsy-bitsy teeny-weeny questions: > > 1. How many .leo files did the previous clashing invocation of Leo open? > > 2. When is *this* invocation going to open all the files opened in the > *other* invocation of Leo? > > Oops! Leo can only run the post-pass after we open *all* the .leo files > opened by the "clashing" invocation of Leo. But Leo has no idea what those > .leo files were! As a result, Leo can *never* be sure a .leo file that is > opened *after* the post-pass won't contain gnx's that clash with > newly-allocated gnx's in *this* invocation of Leo. > > This problem has no solution: it is always too early to run the post-pass! > Leo must create unique gnx's without using a post-pass. > > Terry's Aussie brother Tony reminds us that *no* timestamp format, no matter > how fine-grained, can guarantee that timestamps will *never* collide. I > doubt that SegundoBob's timestamp-adjusting hack will suffice either in > general. > > It seems that the *only* solution is to use uuid's for all newly-allocated > gnxs. This would eliminate the harmful effects of clashing invocations. > Indeed, the notion of clashing invocations disappears if Leo doesn't base > gnx's on timestamps. > > Your comments please. > > Edward > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
