Couchbase Server 2.0 support

[Sam Wilder]

Hello,

With the new version of CouchDB - Couchbase Server 2.0 , I wanted to check whether it will be supported by CouchRest and couchrest_model.

The basic concepts remain same, so it should be fine. However couchrest is not mentioned in the ruby client list there for new upcoming version.

Rgds, 

Sameer.

[Samuel Lown]

Hi Sameer,

Should be fine. I use CouchRest with Couchbase Server with no problems. I'm not sure it'll be officially supported at the moment, but given that Couchbase releases are always based on an official and stable CouchDB API I can't foresee any issues. The same could also be said for Cloudant.

Having said that, if you spot any issues, let us know!

Cheers,

sam

--
You received this message because you are subscribed to the Google Groups "CouchRest" group.
To post to this group, send email to couc...@googlegroups.com.
To unsubscribe from this group, send email to couchrest+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/couchrest?hl=en.

--
www.samlown.com
www.autofiscal.com
www.planetaki.com/sam

[Sam Wilder]

Hi Samuel,
I have done some further probing. It seems Couchbase Single Server is
same product tree as the CouchDb and hence there is compatibility on
the APIs. However the CouchBase Server as such uses the memcached-
based proxy layer in between, which cannot be accessed through
couchrest API but by couchbase-ruby-client API.

There are several advantages which can be seen using the couchbase
server rather than the underlying couchdb server (or couchbase single
server), like having a integrated memcached layer as well as being
able to span across multiple servers in seamless manner.

The catch here is that anything stored directly on couchdb server (say
using couchrest APi) will not be visible through the couchbase layer,
as that brings in concept of vbuckets.

Thus there seem to be compatibility issue which seem to be cropping
in. Is there a possibility of porting the couchrest_model onto the
couchbase server, basing it on couchbase-ruby-client API from
original couchrest API. Should be possible, and would allow users of
couchrest_model to move easily to the couchbase server. I am
particularly fond of the ORM layer which Counchrest_model provides. It
might start with forking the couchrest_model and making it more
acceptable on the underlying API layer (couchrest vs couchbase-ruby-
client)

What are your thoughts on how difficult it might be. What would be a
good starting point? Or is this even the way to go?
It may be encroaching on your efforts, but do you have any plans for
this. Maybe community as such could help.
I am no expert on this, unlike you, so please correct my
interpretation of the issue. Any help in getting forward with it would
be great.

Cheers,
Sameer.

On Aug 25, 2:31 pm, Samuel Lown <sam.l...@gmail.com> wrote:
> Hi Sameer,
>
> Should be fine. I use CouchRest with Couchbase Server with no problems. I'm
> not sure it'll be officially supported at the moment, but given that
> Couchbase releases are always based on an official and stable CouchDB API I
> can't foresee any issues. The same could also be said for Cloudant.
>
> Having said that, if you spot any issues, let us know!
>
> Cheers,
> sam
>

[Samuel Lown]

Hi,

Okay, sorry, I wasn't up to date on the state of Couchbase Server 2.0, I've only used Couchbase Single Server. Frankly, I find the naming very confusing.

Couchbase Server 2.0 is a very different kettle of Fish. While it uses some of the CouchDB designs for Views, its lacking in some of CouchDBs "straightforwardness". I can understand and tell people how CouchDB works, Couchbase Server has a lot more voodoo black magic inside. Even a simple question like "when does my data get written to disk?" is not as obvious. 

As you have said, the concept of "databases" is replaced by "buckets" and that changes quite a few things, especially with regard to some of the newer additions to CouchRest Mode (database proxying is a good example of something that would not be possible with buckets that have to be created manually.)

However, the basic principal of saving documents with properties and searching with views is still essentially the same. It should in theory be possible to rip out the shared functionality (properties, views, dirty tracking, fake associations, etc.) into an independent gem, and then mix them into an new gem for each server type.

My recommendation if anyone has the time and inclination to undertake such a task, would be to create a couchrest_model_support gem, and start moving over the bits that can be shared. You'd then need to create a new version of couchrest to access the new API, and a new version of the couchrest_model for the new type server that includes the support gem.

In the mean time, your best bet is to use CouchDB and Membase as two separate entities and have you models handle the cache fetching. ;-)

Cheers, sam