ENB: Leo as a database

[Edward K. Ream]

This Engineering notebook officially kills a bad idea: that of having Leo "augment" production databases. Indeed, there are two fatal flaws with this idea:

1. Leo can't alter the design of a production db.

2. Leo will choke on huge outlines.

Yes, Leo's leo.db files store outlines as a db. Alas, that doesn't help all that much:

1. Qt could not show the entire outline.

2. Leo's generators could not efficiently traverse large outlines.

Hidden outlines

We could (partially) get around these limitations by designating some nodes (trees) as hidden.  Presumably, these hidden trees would be invisible to Leo's generators.

Leo can already represent arbitrarily large data as uAs, but such data are invisible and (mostly) inaccessible.

Summary

Recently I've considered how Leo might play with production databases. Alas,

1. Leo will never be allowed to alter the design of a production db.
2. Leo will never be able to load (and show) all the nodes of a large db.

Hidden outlines might work in some contexts, but I have little interest in perusing this idea.

Edward

[zhaohe wang]

Yes, I have tested 20,000 nodes. Leo react slowly.  Now I use Leo less than 10,000 nodes otherwise I will create a new .leo file.

[zhaohe wang]

I have already tested leovue. It will be slow if leo nodes over 400.

https://github.com/kaleguy/leovue