1+ for DB::CouchDB even though POST views are not implemented. i use a fair mix of DB::CouchDB and direct REST calls cheers lenz
On Tue, Feb 24, 2009 at 5:13 AM, Jeremy Wall <[email protected]> wrote: > On Mon, Feb 23, 2009 at 5:06 AM, Wout Mertens <[email protected]> wrote: > > Hi all, > > > > I'm trying to convert a Perl script from RDBMS to CouchDB and thus I > turned > > to Net::CouchDb (btw, why CouchDb and not CouchDB?). It doesn't currently > > seem to have an easy interface for reading views, so you have to use the > > call() function which does a plain REST call. > > > > The most difficult part to find out was how to handle the results from a > > call, since they're a pointer to a hash and the rows member is a pointer > to > > an array of hashes. It would be nice if that could be abstracted away, > for > > example behind an iterator interface. > > I do this in DB::CouchDB::Schema. (shameless plug). > > > > > Anyway, this is what I have right now: > > my $answer = $dbh->call('GET','_view/images/all?include_docs=true'); > > if ($answer) { > > %images = (); > > for my $i (@{$answer->{rows}}) { > > $images{$i->{id}} = $i->{doc}; > > } > > } > > > > Is this currently the best way to do it? > > > > The images/all view is a simple > > function(doc) { doc.imgvmxpath && doc.imgname && emit(null, null); } > > which selects all documents that have those 2 keys in them. > > > > I thought that emitting (null,null) and instead using the include_docs > > option would keep the size of the view results to a minimum. > > Is that thinking correct? Does this incur overhead in different ways? > > > > Thanks, > > > > Wout. > > > -- iWantMyName.com painless domain registration (finally)
