Couchbase

[NCBC-139] .net documentation : long values greater than 2^53 need to be stored as string

Tue, 16 Oct 2012 09:36:25 -0500

Please see the following forum questions:

http://www.couchbase.com/forums/thread/severe-bug-2-0-beta-64bit-long-data-wrong-windows-server-2008-r2
http://www.couchbase.com/forums/thread/couchbase-2-0-bet-corrupts-long-c-fields

[NCBC-123] Set, add, and replace should be separate methods

Tue, 23 Oct 2012 17:15:24 -0500

Set, add, and replace should be separate methods

[NCBC-103] Provide Consistent Order of Parameters

Fri, 5 Oct 2012 13:21:43 -0500

Provide consistent, predictable order for method parameters as other SDKS.

[NCBC-102] Provide Standardized Logging

Fri, 5 Oct 2012 13:22:14 -0500

Provides the consistent level of logging provided by other SDKs. Provide more information on configuring logging for developers.

[NCBC-41] As a .net developer, I have an API that allows me to access all of the features of tap so that I can make use of all of the powers of membase.

Mon, 8 Oct 2012 10:42:51 -0500

As a .net developer, I have an API that allows me to access all of the features of tap so that I can make use of all of the powers of membase.

[NCBC-39] Minimize key size by storing as binary array

Fri, 5 Oct 2012 13:38:02 -0500

To reduce overall memory consumption, and make most efficient use of resources, the client should be able to store data as a binary array instead of in a string representation. For example, a GUID which might take 36 bytes as a string can be stored as a 20-byte binary array.

However, the .NET client API doesn't provide any means to store non-string representations of keys, so we're not able to maximize efficiency in this way.

[NCBC-36] Enhance intelligence of client to know about all nodes of a cluster for making REST connection

Fri, 5 Oct 2012 13:33:59 -0500

If configured with a single host (a load balancer), the client will pause for 1s everytime it loses this connection. The same thing happens when configured with a list of hosts and the client reaches the end of the list...it pauses for 1s before going back to the top.

I don't think it's appropriate to ask for the client to constantly spin on trying to make a connection if in fact none can be made.

Another solution to this would be to have the client be aware of ALL the servers in a cluster (which it gets via the vbucket map info) and be able to try all of them, and/or know which ones are alive so that it doesn't have to wait