[Pharo-users] Partition/Sync ready databases for Pharo?

Esteban Maringolo emaringolo at gmail.com
Tue Feb 19 08:36:18 EST 2019


Hi Tim, Pierce,

No problem, I was going to ask about Fossil as well, I know it is a
self contained SCM, with issue tracker, and whatnot. People that uses
it don't want to use git except if forced to.
So I also ask how this would work. :)

I saw SQLite-sync before, but it is a commercial product, and its
platform support/setup seems convoluted.

dqlite might be a viable alternative, from more than reliable
provider, it's is not clear whether I have to use a different library
to access SQLite (it seems so) or a special wire protocol/api calls.
The only drawback I see is that, according to the the FAQ [1], from
the CAP theorem the consensus algorithm puts Consistency and Partition
and leaves out Availability.

I'm looking into CouchDB and reading its "Definitive Guide"[2] book.
It seems straightforward to install, distribute and uses a MVCC
approach that puts availability as its top priority, and since my
domain data has a low probability of conflicts, the eventual
consistency will be more than enough. OTOH I'm not used to document
based DBMS, which will require me to rethink a lot of my domain and
application models.

Also, it has a simple HTTP API (JSON/REST) and there is an existing
Smalltalk client that might be ported and adapted to Pharo
https://cwiki.apache.org/confluence/display/COUCHDB/Smalltalk


Background: I have the prospect to develop an application to replace
an existing one that is a desktop app that "syncs" from/to a central
server every 15', most of the data entry happens locally and the
central server is read only for the most part, it is old, ugly, but it
works "reliably", so I must come with an alternative that is as
reliable as that, and then provide a better UI/UX, new features, etc.

Regards!


Esteban A. Maringolo


[1] From https://github.com/CanonicalLtd/go-dqlite/
Q: When not enough nodes are available, are writes hung until consensus?
A: Yes, however there's a (configurable) timeout. This is a
consequence of Raft sitting in the CP spectrum of the CAP theorem: in
case of a network partition it chooses consistency and sacrifices
availability.

[2] http://guide.couchdb.org/draft/index.html

El mar., 19 feb. 2019 a las 10:03, Tim Mackinnon (<tim at testit.works>) escribió:
>
> When you say Fossil - are you referring to "https://fossil-scm.org/index.html/doc/trunk/www/index.wiki” ?
>
> I’ve seen it come up a few times - is it good? But rather than subvert Esteban’s thread - if it is the above, can you hook into it to save application runtime artefacts such that a distributed application can read them back (I’d just sort of assumed it was for saving code and docs) - but it sounds like it can go a bit deeper than that (which seems quite interesting and perhaps what Esteban is after?)
>
> Tim
>
>
> > On 19 Feb 2019, at 01:46, Pierce Ng <pierce at samadhiweb.com> wrote:
> >
> > On Mon, Feb 18, 2019 at 02:56:10PM -0300, Esteban Maringolo wrote:
> >> I have the requirement that an app that I'm prospecting must be able
> >> to work offline and synchronize changes once the connection is
> >> restored.
> >>
> >> I want to avoid having to write "sync" logic manually.
> >
> > I've not done this for real before, but here are some possibilities:
> >
> > - https://github.com/sqlite-sync/SQLite-sync.com
> > - http://www.symmetricds.org/
> > - https://github.com/CanonicalLtd/dqlite
> > - Use Fossil as your database
> >
> >
> >
>
>



More information about the Pharo-users mailing list