> > > > 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 :-) >
Right ! :) Of course if some of the camping people from the mailing list need MySQL I will be happy to provide some accounts (with no guarantee or support thou :P ) but the idea to upload on a run on the fly only works if you can provide with the db file together with the app. If you have to upload a dump into MySQL first you need a separate account, login etc. seems like an extra complexity. I am not ruling this out completely but if I could do without it ..it might save some time. > > 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?). > Well CouchDB is just running over HTTP so it is fairly easy to handle from my tests but I don't think you can work it it as Sqlite that is embedded. Kirbybase works the same way with the plus that you can open the db file and add entries, modify etc as you please and is entirely made on ruby. With indexes it is pretty fast for me as it loads a lot of stuff in the memory. > > But Couch would be my choice for on/offline data sync, and I'd probably > use Jenna's chill > (https://github.com/Bluebie/**chill<https://github.com/Bluebie/chill>) > and also revisit Knut Hellan's article from 2009 ( > http://knuthellan.com/2009/**03/08/camping-with-couchdb/<http://knuthellan.com/2009/03/08/camping-with-couchdb/> > ). > > Thanks a lot for this Dave I did not know about chill but looks very interesting and will try it today :) Best Regards David > 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 > http://rubyforge.org/mailman/**listinfo/camping-list<http://rubyforge.org/mailman/listinfo/camping-list> >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
