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'
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").commit!
end
# lookup magnus via his email
magnus = FunkyTown.template(:citizens).query(:by_email, key:
'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
http://rubyforge.org/mailman/listinfo/camping-list
