On 07/23/2016 07:05 PM, Ron W wrote:
> Hello,
>
> What you are thinking is not impossible.
>
Thanks for the confirmation, I've been speculating about novel system
architectures and unusual use-cases without sufficient fundamental
knowledge and experience - that makes for dangerous propositions and a
very delicate position. Thanks again, for the sanity check.
> You do need to be aware that Fossil only uses SQLite as an index engine.
> Fossil does not synchronize the actual databases, only the "artifacts"
> (stored as "blobs" in the database). Aside from the blob table, the
> tables in the database are derived from the information in the artifacts.
>
> When information in a Fossil repository is added or updated, Fossil
> creates new artifacts to contain the new or update information, stores
> those in the blob table, then updates the various other tables.
>
We're probably on the same page here. I've recently opened a fossil
repository file with the sqlite3 application and explored the schema
(superficially).
> When Fossil pushes to or pulls from another repository, only blobs are
> transferred. The receiving Fossil adds those to it's blob table, then
> updates the other tables as needed.
>
I think I get the gist of what you are saying. At some point it would
probably be worthwhile [for me] to explore the communication protocol.
> Fossil could be used to synchronize 2 or more SQLite databases. Schema
> updates could be handled as tickets, the body of each ticket containing
> the SQL commands required to make the schema changes. For new clones of
> the database, a serialized version of the schema could be used, rather
> than "replaying" the schema tickets. Synchronizing tables would require
> serializing their content into artifacts, which Could then be
> pushed/pulled normally by Fossil.
>
> The serialization of the schema and the table contents would have to be
> done by an external application. Maybe libfossil could help with that.
> Otherwise, each new artifact could be created in to a file, then the
> files committed into Fossil using system() calls to invoke Fossil's
> command interface. Alternately, the artifacts could be added as wiki
> pages via Fossil's HTTP interface (which would avoid launching the
> Fossil application multiple times, though the push/pull would still have
> to be done via the command interface).
>
That might be an interesting approach to putting together a prototype
demonstration-of-concept system, just using standard Fossil and SQLite
and some scripting.
[The Session Extension](http://www.sqlite.org/sessionintro.html) pointed
out by Eduardo seems to have a lot of potential.
"The session extension provides a mechanism for recording changes to
some or all of the rowid tables in an SQLite database, and packaging
those changes into a "changeset" or "patchset" file that can later be
used to apply the same set of changes to another database with the same
schema and compatible starting data. A "changeset" may also be inverted
and used to "undo" a session."
Wow, whoever designed that extension had Vision.
Given this capability, would you still use Fossil tickets to record,
manage, and communicate the changesets or do you suppose the changesets
(or some variation) might somehow be stored in the blob table?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users