Hi ! First a short update on the camping "on the fly" hosting. Everything is done and tested on the backend. We are just building the frontend (coded using camping) but we are fighting with the strange behavior of the embedded sqlite database (one of my developers is using windows and things are even less user friendly there) - this is not a big issue for the user database but mostly for users that might want to store sqlite backed up. We are getting there thou ! I have seen some traces of camping working with couchDB using ShyCouch but for an odd reason I cannot get the example working.... NoMethodError: undefined method `CouchDatabase'' for ShyCouch:Module and other errors. Couchcamping gem is also based on shy couch so I guess if one doesn''t work the other will be broken too .. ? I wrote to the writer of the lib but before doing more tests has anyone worked on camping + couchdb (even for a quick sample) ? If yes can you email me your working code ? In theory one good thing is that couchdb runs over http so it would be very easy to offer free database and even distribute it across two different severs. I am interested also to get some real cases with couchdb so that we might use it at work too. Thanks in advance David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120425/20361737/attachment.html>
Hi David, Unfortunately, both the ShyCouch and CouchCamping libraries are far from production ready. The former was mostly a learning project, and the latter was.. bad for many more reasons than just that. I don''t think either are of any use for examples, or for something you''d try to support in your new project. However, I''m actively working on some apps where I''ll be using Couch as the data store, so I''m happy to work with you on generating some better, more workable examples. I noticed that you emailed me privately about ShyCouch - sorry for not having replied yet; I''ll get back to you a bit later on when I have some more time. In the meantime, IIRC Jenna has a Couch library that she used in Camping that doesn''t have much bloat and is more Ruby-ish. On Thu, Apr 26, 2012 at 2:36 AM, david costa <gurugeekphp at gmail.com> wrote:> Hi ! > First a short update on the camping "on the fly" hosting. Everything is > done and tested on the backend. We are just building the frontend (coded > using camping) but we are fighting with the strange behavior of the > embedded sqlite database (one of my developers is using windows and things > are even less user friendly there) - this is not a big issue for the user > database but mostly for users that might want to store sqlite backed up. We > are getting there thou ! > > I have seen some traces of camping working with couchDB using ShyCouch but > for an odd reason I cannot get the example working.... > > NoMethodError: undefined method `CouchDatabase'' for ShyCouch:Module > > and other errors. Couchcamping gem is also based on shy couch so I guess > if one doesn''t work the other will be broken too .. ? I wrote to the > writer of the lib but before doing more tests has anyone worked on camping > + couchdb (even for a quick sample) ? If yes can you email me your working > code ? > In theory one good thing is that couchdb runs over http so it would be > very easy to offer free database and even distribute it across two > different severs. I am interested also to get some real cases with > couchdb so that we might use it at work too. > > Thanks in advance > David > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120426/7e408a07/attachment-0001.html>
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... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120426/6b3bbf70/attachment.html>
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...
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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120426/cca67cef/attachment.html>
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 at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120426/50aa6972/attachment-0001.html>
Hello Daniel, thanks for your reply. Well that''s all I needed to know ! I wasn''t sure if it was me or the script not working on couchdb 1.2 and now I know :) Best Regards David On Thu, Apr 26, 2012 at 1:42 AM, Daniel Bryan> > > Unfortunately, both the ShyCouch and CouchCamping libraries are far from > production ready. The former was mostly a learning project, and the latter > was.. bad for many more reasons than just that. I don''t think either are of > any use for examples, or for something you''d try to support in your new > project. > > However, I''m actively working on some apps where I''ll be using Couch as > the data store, so I''m happy to work with you on generating some better, > more workable examples. > > I noticed that you emailed me privately about ShyCouch - sorry for not > having replied yet; I''ll get back to you a bit later on when I have some > more time. > > In the meantime, IIRC Jenna has a Couch library that she used in Camping > that doesn''t have much bloat and is more Ruby-ish. > > On Thu, Apr 26, 2012 at 2:36 AM, david costa <gurugeekphp at gmail.com>wrote: > >> Hi ! >> First a short update on the camping "on the fly" hosting. Everything is >> done and tested on the backend. We are just building the frontend (coded >> using camping) but we are fighting with the strange behavior of the >> embedded sqlite database (one of my developers is using windows and things >> are even less user friendly there) - this is not a big issue for the user >> database but mostly for users that might want to store sqlite backed up. We >> are getting there thou ! >> >> I have seen some traces of camping working with couchDB using ShyCouch >> but for an odd reason I cannot get the example working.... >> >> NoMethodError: undefined method `CouchDatabase'' for ShyCouch:Module >> >> and other errors. Couchcamping gem is also based on shy couch so I guess >> if one doesn''t work the other will be broken too .. ? I wrote to the >> writer of the lib but before doing more tests has anyone worked on camping >> + couchdb (even for a quick sample) ? If yes can you email me your working >> code ? >> In theory one good thing is that couchdb runs over http so it would be >> very easy to offer free database and even distribute it across two >> different severs. I am interested also to get some real cases with >> couchdb so that we might use it at work too. >> >> Thanks in advance >> David >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120426/39e4e948/attachment.html>
HI Nokan :) On Thu, Apr 26, 2012 at 11:02 AM, Nokan Emiro <uzleepito at gmail.com>> > > 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. >I think you are making a very good point. If this was a paid hosting I think that going without MySQL would be pure madness. But let me try to explain: this is going to be a free, not for profit service (I won''t ever make any money with it or offer a paid plan for anything). Despite this caveat users (free or not) tend to expect some level of support to be available. If you offer MySQL you need to be able to help people in some circumstances (e.g. setup, I cannot login, is not working for me etc). If you don''t this would be unusable even on a free basis ! :) But another more important issue is that each application now is inside a BSD jail. The jail can also host the sqlite db without problem. If you give MySQL you need a totally separated MySQL server installed outside the jails... (It would be enough> to have one database for all the users and let the databasename_tablename > structured tablenames solve the rest. >I don''t think that would be very secure :) I wouldn''t want that !> 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... >Oh no you are not silly. You are actually very rational but what you are saying is more relevant for paid hosting. My question to you is why would even a non professional developer (let a lone a professional one) not spend 8$ a month to get unlimited databases and HD space on Dreamhost or a similar service and rely on an experimental, free platform ? I am not sure :) So back to the topic the idea of CouchDB was mostly to experiment and get something new for me to try/play with (which was fun for the last days at least). Another big plus of CouchDB is that, as it runs over HTTP, it is really easy to give space to someone and have this physically on another server. That is interesting. It would also give a chance to users to try something new. And I think this should be the spirit: to be able to try something quickly but not to replace a more stable, paid hosting with support etc. With Heroku, EngineYard and even free EC2 instances is not easy to offer something interesting. I don''t really want to compete with the paid hosting that, rightly so, have to make a living out of this. The ground idea is and remain to let people try camping :) it is not my fault if Sqlite is the default embedded database on camping! On another note SQLite is not so bad. I did write a PHP wrapping for it a long time ago with encryption support etc. (http://sqlite.biz) and I never had an issue. In the wrapping I also had a secure backup method and other things to get sure that you have good copies and check integrity of the DB before running big operations. But Sqlite isn to so new now so I am trying to experiment new things like couchdb. I have also resurrected the old ruby plain file DB KirbyBase and added some camping example in the gem (that now works with ruby 1.8 and 1.9 too) https://github.com/gurugeek/KirbyBase/tree/master/examples/camping_example -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120426/c4c7d83f/attachment.html>
> > > > 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 at rubyforge.org > http://rubyforge.org/mailman/**listinfo/camping-list<http://rubyforge.org/mailman/listinfo/camping-list> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120426/72f29be7/attachment-0001.html>
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: ''magnus at
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 at creativepony.com
(mailto:a at 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 at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/camping-list
> > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/camping-list
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20120427/8ed0617c/attachment.html>
I wonder if you were running SQLite on a linux server which stored your files on a remotely linked drive? Some large hosting companies (mediatemple is a great example) link in your files over NFS or other network filesystems, and those can often be a little buggy with regard to file locking. It''s no big deal, until you have two servers trying to edit the sqlite db at the same time. That can cause corruption, but there''s not really anything the sqlite db guys can do except say not to run it on network drives with buggy file locking. We wouldn''t have that problem on camping''s hosting. SQLite is used for everything from ruby webapps to storing the address book and notes on an iPod Touch. It''s really wide spread and robust. There are almost certainly more instances of sqlite running in the world at any time than oracle, postgres, mysql, combined! I''d bet the email client I''m using to write this is storing my emails in an sqlite database. :) ? Jenna On Thursday, 26 April 2012 at 7:02 PM, Nokan Emiro wrote:> 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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120427/95b77842/attachment-0001.html>
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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120427/33c75b1c/attachment.html>
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: ''magnus at camping.io (mailto:magnus at 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 at creativepony.com (mailto:a at 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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Camping-list mailing list > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120427/d94774cf/attachment-0001.html>
Hi Daniel Good to know the state of ShyCouch and CouchCamping - partly because I''m collecting Camping links and checking their current state: http://dave.camping.sh I''d like to add any Camping apps you''re working on to the above, if they''re public. Dave> Hi David, > > Unfortunately, both the ShyCouch and CouchCamping libraries are far > from production ready. The former was mostly a learning project, and > the latter was.. bad for many more reasons than just that. I don''t > think either are of any use for examples, or for something you''d try > to support in your new project. > > However, I''m actively working on some apps where I''ll be using Couch > as the data store, so I''m happy to work with you on generating some > better, more workable examples. > > I noticed that you emailed me privately about ShyCouch - sorry for > not having replied yet; I''ll get back to you a bit later on when I > have some more time. > > In the meantime, IIRC Jenna has a Couch library that she used in > Camping that doesn''t have much bloat and is more Ruby-ish. > > On Thu, Apr 26, 2012 at 2:36 AM, david costa <gurugeekphp at gmail.com> > wrote: > Hi ! > First a short update on the camping "on the fly" hosting. Everything > is done and tested on the backend. We are just building the frontend > (coded using camping) but we are fighting with the strange behavior > of the embedded sqlite database (one of my developers is using > windows and things are even less user friendly there) - this is not > a big issue for the user database but mostly for users that might > want to store sqlite backed up. We are getting there thou ! > > I have seen some traces of camping working with couchDB using > ShyCouch but for an odd reason I cannot get the example working.... > > NoMethodError: undefined method `CouchDatabase'' for ShyCouch:Module > > and other errors. Couchcamping gem is also based on shy couch so I > guess if one doesn''t work the other will be broken too .. ? I wrote > to the writer of the lib but before doing more tests has anyone > worked on camping + couchdb (even for a quick sample) ? If yes can > you email me your working code ? > In theory one good thing is that couchdb runs over http so it would > be very easy to offer free database and even distribute it across > two different severs. I am interested also to get some real cases with > couchdb so that we might use it at work too. > > Thanks in advance > David > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20120611/3178dc82/attachment.html>