Glad you like it! Chill isn't totally feature complete, but it has the important bits I think. If you ever find yourself needing extra bits I'd love to bulk it out some more - I just haven't had a use for it lately and I've not wanted to design APIs I'm not using myself. Much of the choices were made better by dogfooding (http://en.wikipedia.org/wiki/Eating_your_own_dog_food), I feel. I've been taking a bit of a break from programming lately. I'm learning にほんごそしてひらがな as a productive way to take a break from all this highly logical stuff!
— 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
