Hey, Python client users
gstein at gmail.com
Tue Oct 18 11:12:21 EDT 2011
On Mon, Oct 17, 2011 at 15:13, Russell Brown <russelldb at basho.com> wrote:
> On 16 Oct 2011, at 06:18, Greg Stein wrote:
>> Hey all,
>> The Basho folks have been slow to integrate changes, given their busy
>> schedule with the 1.0 release.
> This is true. Sorry. But we are now putting some time into the client libraries in general and the python client in particular.
No need to apologize! I'd much rather you work on the 1.0 release than
the libraries! I can fix the libraries to my needs; I have *no* idea
how to fix Riak itself. Go wild :-)
>> I've had a couple branches hanging out
>> for a while to deal with HTTP problems and to deal with Issue #53.
>> They've been separate for better review/merging by Basho, but it
>> finally created too many problems for my own work to keep them
>> separate. I've just now merged them into a single branch so that I can
>> get my own work done.
> Yeah, I started merging your P/Rs in a while back, but then the last 2 conflict with a couple of P/Rs from Brett Hoerner. I guess at the point we stalled as there is some decision to be made about the best way to handle pooling.
RIght. Timeouts are needed; Brett is spot-on with that. They're
definitely needed for a production system. The open question is how to
work them into the client, and that depends upon the development
> I'm reading over both Brett and your changes today.
> There is quite some work to merge the commits you've been doing into the official repo, but I'd like to get that done rather than have a competing fork.
To be clear: I'm not attempting to create a long-term competing fork.
I've been using my 'newhttp' branch for proper connections to Riak,
but then I smashed into the lack of .store() returning an identifier.
In the past, I kinda switched branches based on whether I needed good
http work, or .store to work... but I got tired of that. So I created
a new branch and merged it all. And I like to share my work, I like to
help people, and I like feedback. If my fully-merged branch can help
people? Great. Win.
But no... I expect that when you guys (Basho) have cycles, that we'll
figure out the right approach for connection management and get the
committed, and my branches will disappear.
>> Anyhow, enough description. If you're using Python, then I'd highly recommend:
>> I hope that helps, and let me know if you run into any problems with it.
> Would you recommend taking this fork and merging it with the basho/riak-python-client?
I'm building a business based on that branch. So yeah: I have complete
faith in it. I fully believe it is the correct direction to go for the
But: I also sent the P/R to create a discussion on the approach (since
Brett has a different approach, I felt discussion was warranted). I
think it is the right approach, but I did not want to invest time in
full documentation if it was to be rejected. So a merge would be
great, but further documentation would be needed before the next
client release. There will be some test updates since my code
simplifies the set of transports. There is some deprecation of the old
APIs that needs to happen, and I set up the prep-work for that, but
didn't bother with all of that since I was waiting on selection.
The short answer: my branch puts connection management into the
transport, and Brett's patches puts that into the client. A decision
needs to be made, and that will determine future work. I've previously
emailed with an explanation for why I believe the transport class
should handle this (via a connection manager), and why (IMO) the
client should not be worrying about it. Making this decision removes
blocks for future changes (eg. timeouts).
Anyway... I'd merge 'proper' into the upstream master branch (to fix
http and issue 53), and then I'd be on the hook for documentation,
test changes, backwards compat work, etc. I believe it is totally the
More information about the riak-users