ObjC SDK doesn't set length after Database.getBlob()

Mobile Couchbase Lite
1

I found that this Java test BlobTest.testDbGetBlob() run against the ObjC SDK fails because the length is 0. Comparing the Java and ObjC code, there’s no equivalent to the updateSize() function which sets the length. ObjC gets the size here, but doesn’t set the CBLBlob’s length.

I also have a question about this Database.getBlob() API. Java has it annotated as internal, not part of the public API. But the ObjC and Swift doc comments don’t give any indication of the API being internal. Which is it?

2

QueryTest.testQueryGetColumnNameAfter32Items() is another Java test that the ObjC SDK fails. 31 items works. 32 fails.

3

For the test, QueryTest.testQueryGetColumnNameAfter32Items(), we already have fix for the same (3.0.2).
https://issues.couchbase.com/browse/CBL-3356

For the size not updated, will create an issue and track it
https://issues.couchbase.com/browse/CBL-3452

4

Great! Will 3.0.2 be released soon?

And could someone speak to the status of the the Database.saveBlob() and Database.getBlob() APIs? Are they considered internal or part of the public API?

5

getBlob and saveBlob are a grey area. Their use requires a lot of care and there are really strong arguments for keeping them out of the API. They are used by another 3rd party who is doing something similar to what you are doing. We put them in, essentially, for that one customer.

I am not privileged to speak about the published API. I can give you my take: normal users should never use those methods. I can think of very, very, VERY few places where their use is legitimate.

I am also not privileged to speak about release schedule. None the less, I think I can safely say that 3.0.2 will be out “soon”.

6

Thanks, @blake.meike! Based on this, I’ll probably go ahead and leave these functions out of my public API. They are exercised in the tests though, which is how I discovered the length not being set by ObjC.

On the subject of tests, is it safe to assume all tests that exercise the Couchbase Lite public API are in the com.couchbase.lite package? And everything in com.couchbase.lite.iternal.* packages would not be relevant to the public API?

7

That is definitely how it should be. “Safe to assume” is probably, uhhh… unsafe.

8

Haha, I’ll skim through them and see if I find any that might be relevant. So far I have most of the com.couchbase.lite tests working. EncodingTest is one that seems like it should be in the internal.fleece package though. And while LogTest initially seems like it should be exercising the public Logger interface, it’s pretty dependent on the internal package, so I left this one out as well for now.

9

I’ve moved EncodingTests out of the com.couchbase.lite package, as you suggested. LogTest tests a couple of implementation details, but it is, mostly, a test of the Logger API. I’m leaving it where it is.

Thanks!

10

Great, I think that makes sense. I might revisit LogTest and see if I can adapt it without relying on the internal pieces. I didn’t find any tests in the internal package that seemed like they shouldn’t be there, by the way.

11

Jeff: if you can point out the LogTests that don’t belong, I can probably separate them out into a different file. Happy to do that.

12

Thanks @blake.meike. I went through the LogTest class more thoroughly and found that ultimately the majority of the tests are reliant on the internal com.couchbase.lite.internal.support.Log class.

Of the non-test internal dependencies:

import com.couchbase.lite.internal.core.C4Constants
import com.couchbase.lite.internal.core.C4Log
import com.couchbase.lite.internal.core.CBLVersion
import com.couchbase.lite.internal.core.impl.NativeC4Log
import com.couchbase.lite.internal.support.Log

this support.Log class is the biggest one that I’d need to find an equivalent way to call with the ObjC SDK in order to adapt the tests for common code, as it’s making these log calls in most of the tests. Seems like this code might be used similarly on iOS, but it’s not in the public API. It is accessible through these ObjC and Swift APIs, marked for use in unit tests. So it might be safe to use for the same purpose.

Additionally, this one test is using core.C4Log, which requires core.impl.NativeC4Log, which is not even accessible publicly in the Java jar.

Other than that, CBLVersion is used in one test, which is also not clear if there’s a way to access this internal API in ObjC.

I was able to replace C4Constants with the public LogLevel enum ordinals, but this didn’t really help, as it’s only used in the one core.C4Log and core.impl.NativeC4Log test.

Tests that exclusively exercise the public API are:

testLogFileConfigurationConstructors()
testEditReadOnlyLogFileConfiguration()
testSetNewLogFileConfiguration()
testNonASCII()

I guess this makes sense, since the public API is mainly configuration, other than custom loggers. The actual logging is all happening internally.

testNonASCII() is the one non-configuration test that doesn’t call the internal logger directly, instead relying on a query being logged. Unless other tests can be adapted similarly, it may make sense to move them to the internal package.

13

@blake.meike @jayahari.vavachan thank you for the fixes in the 3.0.2 release! This release resolves most of the outstanding issues in my Kotlin Multiplatform bindings. I no longer need to rely on local 3.0.2 builds now. :tada:

14

We, totally, should be thanking you. Your testing is thoroughly appreciated.

1 Like