[PYCBC-214] bucket flush needs to be added Created: 06/Jan/14  Updated: 08/Jan/14

Status: Open
Project: Couchbase Python Client Library
Component/s: docs, library
Affects Version/s: 1.1.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
For a given bucket, there needs to be an easy way to invoke the bucket's RESTful flush(). This should be at the bucket level and authentication level. In other words, for a given bucket that I'm doing set()/get() with, I should be able to flush(). That flush() must use the REST interface for the bucket, not broadcast the libcouchbase/memached flush operation.

Note that it is safe for other client instances to be connected during this RESTful flush() operation. Also, it may be worth mentioning in the docs that flush is not atomic on the cluster and will propagate asynchronously.

 Comments   
Comment by Mark Nunberg [ 08/Jan/14 ]
We currently lack an admin interface; we'd be doing this via the admin interface if we were to support it.




[PYCBC-173] syncwait in design_create() expects "views" key Created: 13/Aug/13  Updated: 13/Aug/13

Status: Open
Project: Couchbase Python Client Library
Component/s: library
Affects Version/s: 1.1.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Volker Mische Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When you call design_create() with syncwait > 0 it polls the design document whether they are there or not. The polling seems to check the "views" key/value. The problem is that the design document might not contain any "views", but only spatial views that use "spatial" as key.




[PYCBC-144] Support PyPy Created: 24/Jun/13  Updated: 24/Oct/13

Status: In Progress
Project: Couchbase Python Client Library
Component/s: library
Affects Version/s: 0.10.0
Fix Version/s: None
Security Level: Public

Type: Epic Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by PYCBC-183 Cannot run on PyPy Resolved

 Description   
I've made some experiments in supporting PyPy.

Supposedly it's CPython compatible -- but not really.

I've started a branch on my own github called https://github.com/mnunberg/couchbase-python-client/tree/pypy

As of now there is no ETA for support - but I'd like to see it working with PyPy as well.

 Comments   
Comment by Mark Nunberg [ 30/Jul/13 ]
Why is this resolved? PyPy is still not supported
Comment by Jai Gupta [ 26/Sep/13 ]
Is this planned to be fixed?
Comment by Mark Nunberg [ 26/Sep/13 ]
I'd like to have it open, but it will require a substantial amount of work to make it work with PyPy. PyPy's C extension layer is sorta broken, so it would require various workarounds in our code in order to play nice with whatever PyPy has.
Comment by Jai Gupta [ 27/Sep/13 ]
When we tested Couchbase python library last time, it used to work with PyPy. I think at that time it was in pure Python. I am not sure though.

Now that Couchbase python library is stable, it does not support PyPy. It is bad for our project.

Is there any workaround? Or, should we run older version of Couchbase python library?

PyPy makes huge difference to our application.
Comment by Mark Nunberg [ 20/Oct/13 ]
So i've done some more work regarding PyPy support. It's leaky and buggy, but 1.2 will have better support than previously. The core problem is that a lot of the stuff the extension does is implemented in pure C. It's easier to maintain and links better with libcouchbase.

* Currently PyPy offers 'cpyext' which is buggy, not to mention being slow. The support in place now relies on CPyExt.

* Changing the code to be pure python would be a bad idea since the overhead doesn't come from a single algorithm but from the overall structure and options provided in our code, not to mention the interaction with libcouchbase. Additionally, the C structure is proven quite well with multiple use cases in Twisted and gevent.

In this category is included interactions with 'cffi' which would be cumbersome and buggy, since all the libcouchbase structures would need to be enumerated properly.

A possible workaround in this case is to maintain the C logic "as-is" and implement the problematic bits in Python, perhaps bridging between the two using cffi - in the case of cffi, we'd only need to bridge the C structures internal to the extension (which are simpler and less numerous than what libcouchbase has)
Comment by Mark Nunberg [ 24/Oct/13 ]
I've started a new project to implement much of the functionality using the 'cffi' module which is supported by PyPy:

https://github.com/couchbaselabs/couchbase-python-cffi




[PYCBC-133] Provide class-level methods by which to not print out long values Created: 13/Jun/13  Updated: 13/Jun/13

Status: Open
Project: Couchbase Python Client Library
Component/s: library
Affects Version/s: 0.11.1
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Mark Nunberg [ 13/Jun/13 ]
If a value is several long KBs and it has an exception, the screen will not be happy :)




[PYCBC-250] support for distributing data by hashkey Created: 03/Jul/14  Updated: 03/Jul/14

Status: Open
Project: Couchbase Python Client Library
Component/s: apidocs, docs, library
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: New Feature Priority: Major
Reporter: Matt Ingenthron Assignee: Matt Ingenthron
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In some situations, users would like to co-locate related data to ensure that failure of a node would affect only related data, rather than a single node failure affecting possibly all user's data. This is referring to supporting the 'hashkey' function that exists in libcouchbase.

 Comments   
Comment by Matt Ingenthron [ 03/Jul/14 ]
Note that I've assigned this to myself as this would need to be considered as part of a bigger change. Couchbase Server is not tested in this fashion where data may be unevenly distributed and having this supported by some clients and not others would be a concern. I wanted to track the request for this feature, however, so I've posted it here.




Generated at Fri Aug 29 03:33:38 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.