Picking up a couple of sentences from a different thread, just for a reference point really, please feel free to ignore ...
On Thu, 11 Oct 2018 10:20:08 -0600, Warren Young <war...@etr-usa.com> wrote: > On Oct 11, 2018, at 12:26 AM, Darren Duncan <dar...@darrenduncan.net> wrote: 8>< -------- >> This makes me think that it would be useful, if it doesn't already, >> for Fossil to have something analogous to a database replication feature. > > That's pretty much what Fossil *is*: a replicated database. Most of > it happens to be blockchain structured, rather than relational table > structured, but much of the table-structured data is also synchronized > between a clone and its parent. Database replication that could be applied to any SQLite database might be a very useful thing, but the Fossil synchronization algorithm is not much help for that, and that sort of database replication is not a lot of use for Fossil. A Fossil repository is a collection of immutable artifacts each named by a cryptographic hash of what it contains, which is metadata and/or content, the latter being a file, or a list of the artifacts in a checkin, or some other things. Artifacts are tied together by the metadata, which contains the names of other artifacts. There are no deletions, and no updates in place (well, there is shunning, but that is a special case for a special purpose). There are quite a few types of artifact. The artifacts are stored as blobs in a table in a SQLite database. There are other tables in the database, but almost all of them can be, and are, populated from the metadata in the artifacts. Fossil synchronization is essentially an exchange of artifacts, followed by each repository populating tables from the metadata from the newly-received artifacts. The "exchange" part of the synchronization knows nothing about tables, rows, and columns. The use of a "relational" database to store a Fossil repository is sort-of incidental. This is nothing like database replication as generally understood, which is commonly done by applying redo (write-ahead) logs from the other side, but it is exactly what Fossil needs. The interlocking of artifacts by cryptographic hashes does seem very much like the same idea as blockchain, which Wikipedia says was invented in 2008. It is interesting that the first Fossil checkin was 21 July, 2007 (and the first git checkin was 7 April, 2005). WARNING: the following sentence will be claimed to be controversial: No database based on SQL is truly relational. But if it was, you could treat a row as an artifact named by table-name+primary-key, ban deletions and updates-in-place, and use Fossil-style synchronization for database replication. Not realistic for most existing databases though. Eric -- ms fnd in a lbry _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
