Mathias
Congratulations. This is a very interesting idea and I think, a true
need for the growing community around Riak.
May I suggest to give a whole chapter as sample? Giving a random
selection of pages doesn't really give an idea on the "depth" of the
book, neither about your writing styl
I have compared drslump vs 2 others, and found the fastest so far is the one
based off of:
https://github.com/bramp/protoc-gen-php
By a factor of 2x. So far DrSlump is the slowest of the three. The refactored
code based off of pb4php comes in at a close second:
http://code.google.com/p/pb4php/
Markus,
You're correct in that backup/restore currently doesn't work with search.
You could still use that method but would have to reindex everything which
would require list keys. In our next minor version method #2 will get
better but it will require you to upgrade. Another method is to writ
Nice!
I had actually done the same thing using DrSlump's protobuf library and
found that it worked quite well and was about 40% faster than HTTP.
I'm curious what your results might be performance-wise comparing what you
have written to DrSlumps (I noticed there is a commit comment about
comparin
I was able to figure it out, and yes, i needed to enable search before
i add things to the test bucket.
Shuhao
On Thu, Dec 22, 2011 at 5:11 PM, Ryan Zezeski wrote:
> Shuhao,
>
> Did you enable search on the 'test' bucket? I'm not sure what the Python
> API is to do that but I don't see it in y
Shuhao,
Did you enable search on the 'test' bucket? I'm not sure what the Python
API is to do that but I don't see it in your code excerpt.
-Ryan
On Sun, Dec 18, 2011 at 1:39 PM, Shuhao Wu wrote:
> I'm having a bit of trouble working with the solr interface:
>
> >>> import riak
> >>> client =
Sorry if it wasn't clear, all the changes are in the transport branch:
https://github.com/gaiaops/riak-php-client/tree/transport
It can be merged into master once we are sure it is production ready.
~ John
- Original Message -
From: "John Loehrer"
To: "riak-users Users"
Sent: Thursday
Past few days I have been experimenting with a protocol buffers client for riak
in php 5.3.
https://github.com/gaiaops/riak-php-client
https://github.com/basho/riak-php-client/pull/20
It is a port of the existing php client and should be backward compatible with
the existing code. Everything
Very true. Still I wonder if there's a way to meet peoples expectations
that list_keys and delete work for buckets way better. Those two things
must be the most requested/commented on things with regard to riak.
Tom
On Thu, Dec 22, 2011 at 11:46 AM, Andy Skelton wrote:
> Buckets have other me
Buckets have other meanings as well, such as configurable values for
n_val, allow_mult, postcommit, etc.
If you think with the multi backend you can come up with many more
interesting uses for buckets.
Cheers,
Andy
On Thu, Dec 22, 2011 at 11:03 AM, Thomas Burdick
wrote:
> It seems like every we
It seems like every week or so someone asks why list_keys is slow or why
they can't delete a bucket. Is it impossible at this point to make buckets
their own keyspace or was that the original intention? Sort of confused by
the entire bucket notion at this point as prefixing my own keys is simple
en
This looks great - Thank you for your efforts.
Tim
-Original Message-
From: "Reid Draper"
Sent: Thursday, December 22, 2011 8:45am
To: riak-users@lists.basho.com
Subject: sumo: a riak clojure client
___
riak-users mailing list
riak-users@list
I ran the queries against the production cluster and could not reproduce
the issue (*whew*). It gave me consistent correct results for the repeated
queries.
The main difference I see is that the data on the prod cluster is written
directly to Riak and on the dev machine it is restored data. Do the
The output from the commands all look normal (just running a single node).
I'm going to see if I can reproduce this outside of this setup.
$ bin/riak-admin ringready
TRUE All nodes agree on the ring ['dev1@127.0.0.1']
$ bin/riak-admin transfers
No transfers active
$ bin/riak-admin member_status
==
14 matches
Mail list logo