On Thu, Jan 14, 2010 at 02:15:54PM -0800, Chris Anderson wrote:
More difficult would be to allow bulk *updates* via this mechanism, because
having parsed out the IDs you'd need to be able to fetch existing docs,
modify and write back.
If the CSV source was responsible for tracking _revs
Hello Kevin,
Not as i know of, i'm practicing the setup and had no databases on the
system (i have two independant couch-N nodes). I installed and
configured as well as i could using the wiki and common sense and some
luck. Then i simply created a new database (using the old google wiki as
a
On Wed, Jan 13, 2010 at 03:18:52PM -0800, Chris Anderson wrote:
I'd think that the document could be 'any old document', with the only
requirement being that it have a specific id (_auth? _security?).
There could be some conventions, but I don't really see why couch
should enforce any
Hey there,
I'm visiting Munich and I thought we could do a small, spontaneous CouchDB
meetup tonight. We're meeting at http://niederlassung.org/ at 19:00. If you are
in town, come by and say hi :)
Cheers
Jan
--
I'll be there as well.
Cheers,
Volker
On Fri, Jan 15, 2010 at 11:29 AM, Jan Lehnardt j...@apache.org wrote:
Hey there,
I'm visiting Munich and I thought we could do a small, spontaneous CouchDB
meetup tonight. We're meeting at http://niederlassung.org/ at 19:00. If you
are
in town, come
Sounds great. I hope there is time come around.
Regards,
Bernd
Am 15.01.2010 um 12:39 schrieb Volker Mische:
I'll be there as well.
Cheers,
Volker
On Fri, Jan 15, 2010 at 11:29 AM, Jan Lehnardt j...@apache.org wrote:
Hey there,
I'm visiting Munich and I thought we could do a small,
This sounds reasonable, but maybe we can make it easier.
You could almost model the manager as a db_admin, but you probably
don't want them editing design documents. So what you need is a set of
roles that apply to particular users, in the context of a particular
database. Maybe it makes more
On Fri, Jan 15, 2010 at 8:52 AM, eric casteleijn
eric.castele...@canonical.com wrote:
This sounds reasonable, but maybe we can make it easier.
You could almost model the manager as a db_admin, but you probably
don't want them editing design documents. So what you need is a set of
roles that
On Fri, Jan 15, 2010 at 1:50 AM, Brian Candler b.cand...@pobox.com wrote:
A couple more thoughts about importing and exporting aggregate batches of
document-oriented data.
* A desktop-friendly way to bundle documents is in a ZIP file.
Unfortunately that's a binary format, and _list/_external
On Fri, Jan 15, 2010 at 12:45 AM, Brian Candler b.cand...@pobox.com wrote:
On Thu, Jan 14, 2010 at 02:15:54PM -0800, Chris Anderson wrote:
More difficult would be to allow bulk *updates* via this mechanism, because
having parsed out the IDs you'd need to be able to fetch existing docs,
GWT does not need a servlet container for talking to json, does it? This
article seems to hold out some hope:
http://code.google.com/webtoolkit/articles/using_gwt_for_json_mashups.html
On Fri, Jan 15, 2010 at 1:04 AM, naren naren.sa...@gmail.com wrote:
I have used GWT in the past and I would
Another one:
It'd be great to have a flood of talk proposals and case studies at OSCON:
Call for participation is open for another week or so.
http://en.oreilly.com/oscon2010
The conference is July 19-23rd in Portland Oregon. Especially stories
of personal experience with CouchDB would be
On Fri, Jan 15, 2010 at 09:32:34AM -0800, Chris Anderson wrote:
list and show should be able to return base64 data, to be decoded to
binary before sending to the client. I know there is a test that _show
can serve a favicon.ico file.
Thank you for pointing that out, I found the _show test.
I
On Fri, Jan 15, 2010 at 2:16 PM, Brian Candler b.cand...@pobox.com wrote:
On Fri, Jan 15, 2010 at 09:32:34AM -0800, Chris Anderson wrote:
list and show should be able to return base64 data, to be decoded to
binary before sending to the client. I know there is a test that _show
can serve a
14 matches
Mail list logo
