Testing the new api, I find that result.getString("_id")
works ok if select(SelectResult.expression(Meta.id),…
but returns null if select(SelectResult.all()
If this is expected behavior, how do I get the document id in the case of the latter.
Thanks
nat
When you select “all”, the entry is a dictionary inside of the result set. The reason it is like this is so that you can keep selecting others things as well (i.e. Select(SelectResult.All(), Meta.ID)) without things trampling on each other. So first get the dictionary from the result set (result.getDictionary(0)). That will have the key you want.
Although now that I say that, I can’t remember if the metadata is included by default or not. It might not be, in which case you can select both if you need both of them (all and ID).
Glad you posted a second time! Because indeed you need to specify _id even for ALL query, like this:
Query query = select(SelectResult.all(), SelectResult.expression(Meta.id)) .from…
Also, it’s available without the need of the dictionary.
Thanks
nat
You will have to explicitly specify the Meta.id and all() in the Select clause.
I would recommend checking out this blog that introduces you to the basics . Examples are in swift but you should find equivalent support in all platforms.
https://blog.couchbase.com/sql-for-json-query-interface-couchbase-mobile/
Of course if you specify Meta.id in the query you will be able to get it without a dictionary. The result will have a dictionary at index 0, and the ID at index 1. The dictionary at index 0 will contain every user property in the document. Looking up by name is just a convenience for getting indexes in a different way.
Yeah, maybe that blog post is better than this: https://developer.couchbase.com/documentation/mobile/2.0/couchbase-lite
Wish you had better [and more] documentation by now. Both are incomplete in many areas, and overlap in others. Anyhow…
hmmm…the link you shared is broken. Did you check this link out ? https://developer.couchbase.com/documentation/mobile/2.0/whatsnew.html
The blog posts are intended to supplement the main docs and discuss specific concepts in-depth and provide a variety of examples .
The docs discuss the core architecture, concepts, detail the APIs and give basic examples.
If there is anything specific that is missing, please provide Feedback via the Feedback link on the docs page.
On the topic of queries, here are some related blog posts
A blog post on JOINs is coming shortly.
Bear in mind that these blog examples are based on Developer Preview DB21 builds so they will be updated for GA but you can at least see the kind of stuff that’s possible.
The url I should have posted is:https://developer.couchbase.com/documentation/mobile/2.0/couchbase-lite/java.html . (Which is a sub page of what you posted in the most recent post.)
Anyhow, basically we need the following.
- Docs for folks that are starting with CBL 2.x
- For developers with api 1.x experience, documentation that directly compares the old way versus the new way in detail. (Yes you do have a general discussion of the ‘new way’, but we need detail per function. With some examples.)
- For developers with experience with SQL, how CBL’s sql differs, and what extra features it offers.
- The API docs - Come on; Needs to be much better! (Basically I am pounding away with the debugger to learn the new stuff.)
- Tutorials and examples synchronized for all platforms.
I really appreciate your asking for feedback. This is a short list.
Thanks;
nat
With regards to number 4, I’m unsure what you mean? For C# I try to make sure that every public function has an API doc comment that gets generated into the API documentation that resides on docs.couchbase.com (as I’m sure our Java lead does as well) but do you have an example for how it is deficient (http://docs.couchbase.com/mobile/2.0/couchbase-lite-java/db021/).
If we had a staff of multiple documentation writers we might be able to accomplish all that you said that we need. The items in 1, 2, 3 could easily take full time attention from someone. I’ll address these one by one though, there might be some information here that is not readily apparent (apologies if it already has been addressed)
- This is probably the most important thing and is what we focus on the most. However since the API has been under extreme flux this has proved challenging. It should sort out now that there are fewer and fewer changes being made.
- Very little of 1.x has any direct bearing on 2.0. Quite literally almost every single line of the 300k line codebase has been rewritten from nothing. I would assert that this is no different than point 1.
- This is an interesting avenue, and one I don’t think any of us had considered yet since SQL is a text based language and query in CBL is a fluent API based feature (although we try to keep in line with N1QL as much as we can so I think that the N1QL <-> SQL comparison could be useful).
- See above
- The mobile travel sample app will be the official tutorial / example app going forward, and furthermore each repo contains a short API walkthrough that is kept up to date with each DB release. We don’t have the resources to update the travel sample app every other week and I for one am hoping we won’t need to once 2.0 is released since the API will stop changing.
With regards to point 4 (since you brought it up first) why not compare the following two api Java Doc pages: (This is just an example. But it’s like this thru out.)
1a. http://docs.couchbase.com/mobile/2.0/couchbase-lite-java/db021/com/couchbase/lite/ResultSet.html
1b. https://developer.android.com/reference/java/sql/ResultSet.html
Ok now to point 2. The fact that the codebase is new code, has nothing to do with my point, which is that a seasoned developer needs to know how to do things the new way as compared to the old way. The developer could care less if 1% or 100% of the code is new. The fact is that now, in order to accomplish the SAME functionality, a different methodology need be utilized. And that needs guidance and explanation of benefits, for many many of commands and syntax commonly used.
Thanks
nat