In the Android docs, the example code in the Fleece data encoding section won’t compile:
Map<String, Object> doc = collection.getDocument(someDoc.getId()).toMap();
Long testVal = Long.valueOf(doc.get(“test”))
(Besides the missing semicolon), Long.valueOf() requires either a String or long, where doc.get("test") is an Object, which would need to be explicitly cast to one of these types first. It’s not actually clear what this code is demonstrating.
I don’t see a similar section in the Java or other SDK docs.
Care should be taken when storing and recovering data in a document or converting that document to JSON and back.
Data encoding (Fleece) can result in Long values being converted to Float instead of Double.
Interpreting data as boolean can also give inconsistent results.
I believe the toArray method referenced here should instead be toList() for the Java SDK. It also says “see Example 4”, instead of the correct Example 12.
It also references Example 4 instead of 12 here:
Initialize a ‘MutableArrayObject’ using data supplied as a JSON string. This is done using the init(json) constructor — see: Example 4
Also, references to ArrayObject and MutableArrayObject are not correct for the Java SDK, where these objects are just called Array and MutableArray.
There’s also not an ArrayFragment API in the Java SDK and I don’t understand what this means in relation to the SDKs that do have the subscript fragment API:
Convert an ArrayFragment object to a JSON String
Similar issue with the Dictionary documentation referencing toDictionary instead of toMap() and using DictionaryObject and MutableDictionaryObject instead of Dictionary and MutableDictionary.
The code for Example 14. Using a Parameter seems to be Swift? (except it uses semicolons ) The code block says it’s Java. Anyway, the same code is used in all the SDKs’ docs and I don’t even think the API is correct, as Query is an interface. I believe the Kotlin code should be:
val query = database.createQuery("SELECT name WHERE department = \$department")
query.parameters = Parameters().setValue("department", "E001")
val result = query.execute()
Also, oddly there’s another section for Query Parameters at the very bottom that does have a correct example. Maybe these sections should be combined?
There are a lot of examples throughout the docs where the formatted single (‘’) and double quote (“”) characters are used within code blocks, instead of the proper ’ and " characters, for example under the string literal syntax and example. This makes it difficult to copy/paste these code samples, and can be confusing to a user when it doesn’t work, with a potentially strange syntax error. I’m sure the intention was to use these characters properly in non-code text, but may have leaked into the code block text as well.
In the QueryBuilder Differences table, I believe “Match Functions DIV IDIV ROUND_EVEN” is meant to be its own row, rather than bundled with Conditional Functions components, and should be “Math Functions”.
You are having a regular old good time, aren’t you?
Seriously, I cannot thank you enough for your close reading of this stuff. The docs team is on it.
WRT:
Map<String, Object> doc = collection.getDocument(someDoc.getId()).toMap();
Long testVal = Long.valueOf(doc.get(“test”))
… the point (entirely missed by the sample code) is that even if you store a Long at key “text”, if you don’t explicitly ask to get a Long back, you may get an Int: Fleece loses the type information and uses the smallest representation that doesn’t lose accuracy.
Haha, yes, going through the docs with a fined tooth comb! I’ve been working on getting some docs put together for my Kotlin Multiplatform CBL library. It’s a good opportunity to fill in my Couchbase and SQL++ knowledge reading the CBL docs in full along the way.
I was thinking this might be what was trying to be communicated. So something along these lines:
val doc: Map<String, Any?> = collection.getDocument(someDoc.getId()).toMap()
// "test" value may be an Int, even if originally set as a Long
val testVal: Long? = (doc.get("test") as? Number)?.toLong()
By the way, I should be close to releasing my library, now that these changes are soon to be available in a public release!
I can take this one. It means that while on server when you use OFFSET, you must have a LIMIT clause as well, you can use OFFSET alone in SQL++ on mobile.
) The code block says it’s Java. Anyway, the same code is used in all the SDKs’ docs and I don’t even think the API is correct, as 
