2

I just read SQLite As An Application File Format. While it makes a great case for using SQLite as a persistence layer for single user, single device type apps; it does not seem to lend itself well for multi-device or multi-user and multi-device applications that require frequent synchronization.

I've been looking for a SQL or NoSQL persistence layer that meets the following requirements:

  • GPL compatible licensing
  • c/c++ API
  • native synchronization/replication capability
  • Ability to run on at least GNU/Linux x86_64 and Android ARMv7, MIPS, Windows, OSX, iOS optional.

So far, the only option I have discovered is Couchbase and I've been having issues with it. That led me to wonder whether it was reasonable to use Git (or another SCM) plus JSON files as a persistence layer. That prevents rewriting the synchronization wheel.

While it is obviously possible, since git is basically a distributed file system at heart, I'm unclear on the practicality of this as a solution and what pitfalls might lurk. Anyone have any specific experience on using git as a persistence layer?

justinzane
  • 1,897
  • 1
  • 26
  • 38
  • do you actually need the history conservation part of git? how do you plan on solving the conflicts? – njzk2 May 26 '14 at 19:52
  • @njzk2 Thanks for that. I'm pretty sure that on the "server" side, there will not be a provlem holding all the history. On the client side, likely all that will be needed is the current head; everything else can be deleted. And, as far as conflicts go, probably with a simple last version wins. Need to play that out more, though. I appreciate the insight. – justinzane May 28 '14 at 01:59
  • git usually keeps the complete history in each repository (by its decentralized nature). I think there is a possibility to automatize merging based on commit dates, possibly with a little scripting. you may want to look at synchronization systems like rsync or webdav-based systems – njzk2 May 28 '14 at 13:20
  • @njzk2 I've had miserable problems getting webdav to work with on GNU/Linux only as server and client. Not likely to want to mess with again. And rsync might be interesting, though there would be a clock synchronization issue I think. – justinzane May 29 '14 at 23:07

0 Answers0