So far as uploading a couchdb to a git repository - You could probably find the files somewhere in your system and do that, but it sounds like a bad idea. Better: use wget to download the all_docs page, backing up all the documents on that database in to a single file. Then you can restore it by wget posting it to a new server, effectively doing a bulk commit. Quick, easy, readable text file containing json and newlines IIRC. It might take some tinkering to get it to include your design documents too, but if you're chillin' you can just rerun the file which updates them to recreate those.
— Jenna On Thursday, 26 April 2012 at 9:09 PM, Dave Everitt wrote: > Hi Nokan > > I'm a professional newbie (simply because I use and teach a wide range > of stuff and only go deep when I have to :-) > > As I'm sure you're aware, as an embedded lightweight database SQLite > makes an easily-managed default setup (as in Camping... and Django, > and even within OS X and, of course... RoR), but if you need a client- > server database I'd say that's beyond the test server remit and would > be a whole other setup/maintenance layer for David :-) > > SQLite is fine for me simply because I don't need anything bigger, and > I can include the db file in a git repo (don't know yet if that's easy > with CouchDB - anyone?). > > But Couch would be my choice for on/offline data sync, and I'd > probably use Jenna's chill (https://github.com/Bluebie/chill) and also > revisit Knut Hellan's article from 2009 > (http://knuthellan.com/2009/03/08/camping-with-couchdb/ > ). > > DaveE > > > Hi, > > > > In a previous thread I was declared as a newbie end user, now I'll > > behave > > like that :) > > > > If I'll use the hosting service, I'll want to be able to use mysql > > and not sqlite, > > and other experimental solutions. You can say that this is silly of > > me, but, > > as an end user, I have the right to be silly. BTW I have bad > > experience > > with sqlite. It can happen that the database becomes corrupted > > somehow, > > maybe because of not properly handled concurrent accesses, or a ctrl- > > c in > > a bad moment, I don't know. And mysql is faster too. As a silly > > end user > > I would prefer a separately existing permanency layer. This is not > > a problem > > for active record, so I really don't get it why not to use it. (It > > would be enough > > to have one database for all the users and let the > > databasename_tablename > > structured tablenames solve the rest. Actually the users don't need > > to know > > where is the data stored and how, just use the ActiceRecord API, but > > they > > need to know that it's fast enough and the data is securely stored.) > > > > I'm sorry, I know I was not really constructive... > > > > ...end users are always silly... > > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
