First encounter with the sync gateway

[Francisco Garcia]

I have just started playing with the sync gateway. But I am having some difficulties (notice my bias coming from CouchDB)

1. First thing I tried was using curl to create a document through the admin interface (and verified that '_all_docs' does not fail)

>  curl -X PUT -d '{"name":"bob","channel_id":"kuku"}' http://localhost:4985/rubase/bob

{"error":"Unsupported Media Type","reason":"Invalid content type application/x-www-form-urlencoded"}%

After a while fighting with it, I noticed in the docs that the Admin API does not seem capable of creating plain documents. Is that right? 

2. I tried the same operation logged as a user. After a while with no success, explored the docs and noticed that there is no PUT database/document and the supported PUT operations seems to show that learning to use the gateway with curl is not so trivial.

3. I had some documents already in my CouchBase bucket, so I wanted to see if I could get them listed with 'all_docs'. The sync-gateway doc mentions that you just need a "channels" array in your doc, the ChatDemo mentions "channel_id" but adding those does not work. Reading the view/channels it seems that some extra document fields are needed.

What the easiest way to make existing documents in CouchBase visible in the gateway?

4. I tried the Chat Demo for iOS (beta1 and beta2, in both cases trying the default server and a local one). The app launches straight into the Chats view. After clicking the "+" button I get an alert about not being logged. How can I do it?

Well, that is all for now. I wanted to get past these points to learn-explore more about the sync function and write one to make many users to access the same bucket. Looks like it is just giving each user its own channel 

thanks in advance

Francisco

[Jens Alfke]

On Jan 17, 2014, at 12:04 PM, Francisco Garcia <pub...@francisco-garcia.net> wrote:

>  curl -X PUT -d '{"name":"bob","channel_id":"kuku"}' http://localhost:4985/rubase/bob

{"error":"Unsupported Media Type","reason":"Invalid content type application/x-www-form-urlencoded"}%

Look at what the error message says. You need to set the request Content-Type to application/json. (Pretty sure CouchDB would complain the same way.)

Actually I recommend switching to HTTPie from curl — it makes sending JSON requests vastly easier, including automatically setting the content type.

After a while fighting with it, I noticed in the docs that the Admin API does not seem capable of creating plain documents. Is that right? 

No, the admin API is a superset of the regular API.

2. I tried the same operation logged as a user. After a while with no success, explored the docs and noticed that there is no PUT database/document

Yes, there is. Maybe the docs are wrong; can you show me where it says this?

3. I had some documents already in my CouchBase bucket, so I wanted to see if I could get them listed with 'all_docs'.

It's possible to make the gateway add metadata to existing docs in the bucket to make them accessible via the gateway. In the database configuration object set the property "importdocs" to true, then restart the gateway.

—Jens

[Francisco Garcia]

Am 17.01.2014 um 22:13 schrieb Jens Alfke <je...@couchbase.com>:

>
> On Jan 17, 2014, at 12:04 PM, Francisco Garcia <pub...@francisco-garcia.net> wrote:
>
>> > curl -X PUT -d '{"name":"bob","channel_id":"kuku"}' http://localhost:4985/rubase/bob
>> {"error":"Unsupported Media Type","reason":"Invalid content type application/x-www-form-urlencoded"}%
>
> Look at what the error message says. You need to set the request Content-Type to application/json. (Pretty sure CouchDB would complain the same way.)
>

arg! shame on me! I ignored that curl was giving me that error because CouchDB did work for me:

> curl -X PUT -d '{"name":"bob","channel_id":"kuku"}' http://couchdb.dev/rubackup/bob2
{"ok":true,"id":"bob2","rev":"1-7fd06dfd6556031ca52a90777ae50ca2"}

> Actually I recommend switching to HTTPie from curl — it makes sending JSON requests vastly easier, including automatically setting the content type.

But that is shell only isn't it? Using curl was for the email, but normally I use this Chrome extension:

http://www.getpostman.com/

I highly recommend it for any REST api, it is a breeze to set up different authentifications and even more important, to save sample requests

However there is a bug. When I saw the content type error, I thought this extension was setting the right type.

Here are some screenshots for you to make it work right (and for my bug report to them)

https://www.evernote.com/shard/s44/sh/63f82a12-5e80-40e3-8dcb-eb257eb2e1a0/f90c9cab605b3a03f61fb90b71595e9c
https://www.evernote.com/shard/s44/sh/b8d738d3-cdf9-47dd-b0f9-a17f1c18a906/0271759b0067d93e88668444b6fe051e

Hope you like it, it would be great for once after all your help, being able to make you discover something new that eases your workflow

>
>> 2. I tried the same operation logged as a user. After a while with no success, explored the docs and noticed that there is no PUT database/document
>
> Yes, there is. Maybe the docs are wrong; can you show me where it says this?
>

Here!

http://docs.couchbase.com/sync-gateway/#http-requests

But my mistake was exploring the code like commented some lines above. Even I've just found the line for that

https://github.com/couchbase/sync_gateway/blob/master/src/github.com/couchbaselabs/sync_gateway/rest/routing.go#L55

>> 3. I had some documents already in my CouchBase bucket, so I wanted to see if I could get them listed with 'all_docs'.
>
> It's possible to make the gateway add metadata to existing docs in the bucket to make them accessible via the gateway. In the database configuration object set the property "importdocs" to true, then restart the gateway.
>

That will prove very useful within a future. And I've just verified such amazingly useful property is not mentioned in the docs:

http://docs.couchbase.com/sync-gateway


Now looking at generated bucket doc, can't help but have some new doubts:

1. "importdocs", "_sync"... is there any list of Reserved Property Names (along design document ids) for CouchBase products that developers could use as reference to avoid future conflicts with our documents?

2. I've just understood how to use the sync functions and map a property tot he _sync/channels array!

When multiples users access the same bucket and mostly can read only their own docs:

Is the common practice mapping each user its own channel?

Should I ideally store always the user name / channel as a prefix of every document "_id" instead using a document property?

I understand the risk of non random 'id' conflicts using properties, but not sure if there they have any advantage

3. Looking at my bucket, noticed that the same document will show a different "rev" field when exploring the bucket through the SDK

https://www.evernote.com/shard/s44/sh/fdba6cfc-7543-43ba-b0f1-e22c2308d38b/43e99f8eda51ac855e06b2dcb6b9d6a6

Is that expected? I am concerned about having a mobile app (through gateway) + web app (through SDK). The SDK is what I have when using Ruby, but it seems dangerous touching documents considering the info inside "_sync". Should I prepare to implement my Ruby web app using the gateway? If yes, will CouchRest (ruby gem) give us the Gateway-SDK for Ruby?



Well, that makes my day! Thanks to you I learnt a lot today. Have a great weekend Jens!

-- Francisco

[Francisco Garcia]

>
>>
>>> 2. I tried the same operation logged as a user. After a while with no success, explored the docs and noticed that there is no PUT database/document
>>
>> Yes, there is. Maybe the docs are wrong; can you show me where it says this?
>>
>
> Here!
>
> http://docs.couchbase.com/sync-gateway/#http-requests
>

Just found a much better API description here

http://docs.couchbase.com/couchbase-lite/cbl-api/#put-dbdoc

Now everything makes sense. When testing the gateway installation, the whole time my mind was set to "Gateway running, look for the Gateway API" when actually, the API was inside the CBL documentation. I ignored this thinking that I should not deal with HTTP REST calls inside CBL

[Jens Alfke]

On Jan 17, 2014, at 11:52 PM, Francisco Garcia <pub...@francisco-garcia.net> wrote:

Now everything makes sense. When testing the gateway installation, the whole time my mind was set to "Gateway running, look for the Gateway API" when actually, the API was inside the CBL documentation. I ignored this thinking that I should not deal with HTTP REST calls inside CBL

You realize it's just the CouchDB API, right? (Or rather, large subsets of it, plus extensions.)

—Jens

[Francisco Garcia]

I did notice the similarities, and that is the reason I decided to explore the gateway using REST calls before looking at the CBL examples

However regarding the concern I mentioned in my previous reply (regarding Sync Gateway SDK and possible corruption using CouchBase SDK)

If the intention is to keep as much compatibility as possible with the CouchDB API. There is something that could 'potentially' make the gateway compatible with many third party libraries. For example, this is how I add a document to CouchDB with Ruby:

db = CouchRest.database('http://localhost:4985/rubase/')
db.save_doc({key:'joe'})

However with the Gateway the above call fails with:

RestClient::MovedPermanently: 301 Moved Permanently

I believe it is only because the gateway redirects instead of accepting urls with/without final '/'

Although each library implementation is different. It looks like accepting instead redirecting could potentially ease the compatibility with CouchDB clients in many languages.... but I am not sure how much compatibility is intended, and if we should just blame the implementation I am using now

[Jens Alfke]

On Jan 18, 2014, at 2:34 AM, Francisco Garcia <pub...@francisco-garcia.net> wrote:

      db = CouchRest.database('http://localhost:4985/rubase/')
      db.save_doc({key:'joe'})

However with the Gateway the above call fails with:
       RestClient::MovedPermanently: 301 Moved Permanently
I believe it is only because the gateway redirects instead of accepting urls with/without final '/'

I would say this is a library bug — it should be following the redirect instead of treating it as an error (a 3xx status is not an error.)

But yeah, it would be better for compatibility if the gateway accepted requests to "/db" instead of redirecting them to "/db/". Unfortunately this is a behavior of the HTTP routing library we're using (GorillaMux) and when I looked into it a few months ago I couldn't find a clean way to change this behavior.

—Jens