Will the Android com.couchbase.lite.Mapper.map function be excuted in parrallel by several Threads?

[john....@gmail.com]

The com.couchbase.lite.Mapper.map function is supposed to be side effect free.
Does this mean that it might be called by Couch by several Threads?

[Jens Alfke]

On Oct 13, 2015, at 2:48 AM, john....@gmail.com wrote:

The com.couchbase.lite.Mapper.map function is supposed to be side effect free.
Does this mean that it might be called by Couch by several Threads?

Yes, it might be. It isn’t, in the current implementation, but that’s an optimization that could be made in the future.

(I did try this experimentally about a year ago, on iOS, but it didn’t improve performance. On a two-core CPU the overhead of managing the parallelism cancels out the benefits.)

The main reason to avoid side effects is that you have no idea when the map function might run. It’s probably on a background thread, and the timing and the order of index updates is implementation-dependent. So don’t use or modify any external state.

—Jens

[john....@gmail.com]

Thanks for clarifying. I know that I should not recreate the view index that often because its not the performance most tuned operation.

But yet I do need to do this  because I have a dynamic query which is nearly impossible get done with only the query api. (I would need to create a lot of views and merge the results)

Any advice on  how  I can speed up execution of the map function on android? For what should I look out? For example I am calling emit a lot for a single document.

[Jens Alfke]

On Oct 13, 2015, at 2:16 PM, john....@gmail.com wrote:

But yet I do need to do this  because I have a dynamic query which is nearly impossible get done with only the query api. (I would need to create a lot of views and merge the results)

If this really is a one-shot view that’s just queried once and then deleted, then it might be cheaper just to do the work yourself in memory. That is, you’d run an all-docs query to iterate over all documents, do your mapping logic on each, and collect and sort all the emitted data. This will use more RAM than a one-shot query, but you’ll save all the disk I/O of writing the index and then reading it back in.

Any advice on  how  I can speed up execution of the map function on android? For what should I look out? For example I am calling emit a lot for a single document.

Building an index from scratch is inherently expensive — it reads every document from disk, parses it, evaluates the map function, serializes the index rows and writes them to disk. You can profile your app to see how much of the time is being spent in your map function itself.

—Jens

[john....@gmail.com]

Thanks Jens your answer is right to the point.

Since you helped me so much I dare to ask another question.

Since I am not using Couchbase on the backend  I just saw that that Lite supports the couchdb replication protocol.

Now I am trying to guess how much work it would be to write an CouchDb Replication Protocol Adapter for my custom java backend?

Right now I am doing all the syncing couhbase-lite with a homegrown protocol. With /get-documents and /poll-for-changes rest calls.

If you would recommend writing an Replication Adapter, to get me started are there any docs or are there any code examples available?

Many Greetings

John

[Jens Alfke]

On Oct 13, 2015, at 10:35 PM, john....@gmail.com wrote:

Since I am not using Couchbase on the backend  I just saw that that Lite supports the couchdb replication protocol.

Yes; we use the CouchDB protocol with a couple of minor additions for performance. If CBL detects that it’s talking to CouchDB it’ll avoid using the additions, for compatibility.

Now I am trying to guess how much work it would be to write an CouchDb Replication Protocol Adapter for my custom java backend?

A lot; on the order of a man-year, I’d guess. What you’re talking about is roughly equivalent to a big chunk of Sync Gateway (which is at heart a CouchDB replication protocol adapter for Couchbase Server.)

As part of that, you’ll have to figure out how to map your back-end’s data model to the multi-version (MVCC) Couchbase Lite document model, which is not trivial. (Again, speaking from experience.)

It would be much easier to have the client replicate with Sync Gateway, and then build glue for your back-end to talk to either the Gateway or Couchbase Server directly.

—Jens

[john....@gmail.com]

I thought that Sync Gateway is "just" an adapter for adapting couchdb protocol to couchbase server.

concluding from your response sync gateway is much more? How can I plug into the synch gateway? does it often any abstraction for this?

[Jens Alfke]

On Oct 13, 2015, at 11:04 PM, john....@gmail.com wrote:

I thought that Sync Gateway is "just" an adapter for adapting couchdb protocol to couchbase server.

Thanks for putting “just” in quotes :)

concluding from your response sync gateway is much more?

It also handles document access control and routing through a “channels” mechanism, and also user authentication. This is all documented on our website.

How can I plug into the synch gateway? does it often any abstraction for this?

The Gateway’s database can be accessed by server-side app code via a REST API. It includes a “_changes feed” that you can read to monitor changes to documents. Search for [changes worker pattern] on the website to see info and sample code.

—Jens