Couple of questions about CouchbaseLite

I posted this on the Mobile Couchbase Google Group, but will post here as well......

My largest question is when will this be bound properly to use the native C# stuff ie. Dictionary vs NSDictionary, string vs NSString etc...?

Due to this I cannot enumerate over a query's rows since Couchbase.QueryEnumerator does not implement IEnumerable. The only way I've found to do so is like so:

for(var i = 0; i <query.Rows.Count; i++)
var item = query.Rows.RowAtIndex((uint)i);

If there is a better way please advise.

In the above example, my query has about 1700 rows. Using the above, it takes several minutes just to loop through and print the keys or values. It's just extremely slow and not really acceptable for my use case.

I need to query certain keys within the returned documents and was planning to dump the rows into a list and use LINQ as I don't see how else I could do this at present.

Am I approaching this the wrong way? I'd like to have the rows from a query be retrievable as a native C# Generic Collection without me having to manually populate.


  • ZacharyGramanaZacharyGramana USMember Xamurai
    edited November 2013

    @FrancisFernandes, we are working on a solution that will also remove all Cocoa specific types that leak into the iOS binding.

    As for the query, what problem you are trying to solve? Otherwise, I have no way to tell if there is a better way or not. I suspect, however, that you should be using a MapReduce view. These are very fast over, even over large datasets.

    I just released an update that demonstrates using a MapReduce view to compute aggregate values (in this case, a count of items remaining to purchase). In your case, you can probably just pass null in for the reducer function.

  • Zack,

    I am using a MapReduce view in order to get that query. I'll give you a little bit more context...

    I have several products in my db. The document id's are structured like product::235, product::456 etc...

    I use the MapReduce to emit productID as the key and the actual document as the value, just as shown in the examples I've seen. The problem is, I need to filter those products now by values in the document. Let's say for argument sake there is a Calories key in each product document. I want to filter products out that have less than 500 calories. My understanding is I need to do this with the query that is returned from the view.

    Since everything is using the native Cocoa types, I can't iterate over the rows with a foreach, so how can I get these document values into a native C# collection for filtering via LINQ, other than doing it in my above post(which would include validating the row and pushing valid ones into an ICollection)?

    I was under the impression I shouldn't have any of the filtering logic in the MapReduce as it is supposed to act as an index, nevermind the fact that I need to be able to change the filtering variables which isn't how the views are supposed to work.

    Maybe I'm missing how this is supposed to work, but the way I'm approaching it is basically what is outlined in the official documentation.

  • Zack, please note the response that Jens just gave me in the google group. Looks like the performance issue was exactly what he was saying. I will link to it here for others.!topic/mobile-couchbase/RAibepsWsbY

    In short, referencing query.Rows will execute the query each time, so by assigning query.Rows to a variable and then iterating over that, I am working with the result set as opposed to firing off the query for every iteration of the loop.

  • Any update on this? I'd really like an updated Xamarin component since there have been a fair amount of additions/changes to the native library since then. Also really looking forward to using the native C# syntax and dumping the ugly Obj-C NS* stuff that I'm currently forced to use. Wanting to release the app I'm using this for, but prefer to wait on an up to date component.

  • ZacharyGramanaZacharyGramana USMember Xamurai

    You can watch the repo at (for now, will likely move in the future).

Sign In or Register to comment.