Sorry correction - the argument to ChillDB for setting your password is pass: 'hackerbats', not password: 'hackerbats'. Silly me! Maybe chill should accept both!
— Jenna On Friday, 27 April 2012 at 1:47 AM, Jenna Fox wrote: > Sure. To connect chilldb using a username and password: > > ChillDB.goes :CakeTown, user: 'david', password: 'hackerbats' > > To connect it to a remote server: > ChillDB.goes :YellowBrickRoad, host: 'davidcosta.camping.io > (http://davidcosta.camping.io)' > > You can combine those to level up, and even add a port setting if you like! > > To make a database with some users you could do this: > ChillDB.goes :FunkyTown > > # make a little template for our citizens - this doesn't do anything to the > server, it's just in ChillDB's memory > FunkyTown.templates( > # creates a citizen template - note that an extra property - kind: > 'citizen' is implied unless you specify otherwise, for convenience when > writing views > citizen: { > name: unknown, > email: nil > } > ) > > # add a design with a view to get citizens via their emails > # you only need to run this once to setup the site - it stores it to the > server > # it doesn't matter if you run it whenever you restart the servers though - > it just means couchdb has to recompute the views, which maybe a bit slow on > sites with lots of documents > FunkyTown.design(:citizens).views( > # for all the documents which have a 'kind' value of 'citizen' and have an > email set, we list them in the by_email view > by_email: %q(function(thing) { > if (thing.kind == "citizen" && thing.email) emit(thing.email, thing); > }) > ) > > # add some people > people = ['david', 'daniel', 'nokan', 'dave', 'jenna', 'magnus'] > people.each do |person| > FunkyTown.template(:citizen).merge!(name: person, email: > "#{person}@camping.io (http://camping.io)").commit! > end > > # lookup magnus via his email > magnus = FunkyTown.template(:citizens).query(:by_email, key: > 'mag...@camping.io (mailto:mag...@camping.io)') > > couchdb is a simple thing, so if you need the ability to select all users, > you do that by making another view which lists all the documents where > document.kind == 'citizen' for this example. There's no magic way to do those > sorts of queries - you need to tell the database in advance. CouchDB does > actually have a facility for creating 'temporary views' - but chill doesn't > implement it and couchdb guys explain in harsh words in their docs that it's > not for use in production environments - it's just for playing around testing > views before you're sure what you want. CouchDB has a nice little web > interface (like a pretty and simple phpmyadmin) built right in where you can > try out views like that, so I didn't see the need to have it in chill. > > CouchDB also has a special all_docs thing you can load, which is basically a > view with everything in it. This way you can just do normal select, find, > map, reduce, etc, with normal ruby arrays and things, if your data set is > small enough that you don't need all of this stuff cached in the database > itself. > > Chill doesn't do conflict validation, and it shouldn't. CouchDB doesn't work > that way. You don't avoid trouble by validating that a user doesn't exist > then creating them, you avoid trouble by making sure that when you look up a > user and find there is two of them, you have some way to merge them or flag > it up for an admin to fix. Once you have more than one database server or > more than one web server process, you can't depend on the database keeping > things like that sane for you. You could check the user doesn't exist yet, > then another server could check, create the user, then you create the user > also, and now there's two of them. It's good for the web ui to try and block > this stuff - it just can't be guaranteed without making huge sacrifices to > concurrency. As CouchDB can run in a p2p structure (masterless) there's no > single database you can talk to who can make promises like that, and > databases can even run disconnected from each other then sync up later - neat > for mobiles and the likes. > > — > Jenna > > > On Friday, 27 April 2012 at 12:37 AM, david costa wrote: > > > Hello Jenna, > > I like chill too ! > > Is it possible to have a simple example with db connection (I see you have > > this on ChillDB::Database but just wanted to get something simple to cover > > the username/password and/or remote couch server with a different URL than > > localhost) > > > > and again a very simple usage to keep a database of users and a map > > reduce/view to select a user by email, select all users and perhaps > > validate if a user already exist ? :P > > Thanks > > David > > > > > > On Thu, Apr 26, 2012 at 2:55 PM, Jenna Fox <a...@creativepony.com > > (mailto:a...@creativepony.com)> wrote: > > > 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 (mailto:Camping-list@rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > > 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 (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
