TtlDb.java doesn't set default column family handle

[dtanner]

Expected behavior

TtlDb.java newIterator() should successfully use the default column family handle similar to how it works when using RocksDB.java.

Actual behavior

It fails with:

java.lang.NullPointerException: Cannot read field "nativeHandle_" because "this.defaultColumnFamilyHandle_" is null
	at org.rocksdb.RocksDB.newIterator(RocksDB.java:3241)

because the defaultColumnFamilyHandle_ wasn't set up in the 2 and 4 arg open methods of TtlDb.
e.g. RocksDB's open implementation that configures the default column family handle:

  public static RocksDB open(final Options options, final String path)
      throws RocksDBException {
    final RocksDB db = new RocksDB(open(options.nativeHandle_, path));
    db.storeOptionsInstance(options);
    db.storeDefaultColumnFamilyHandle(db.makeDefaultColumnFamilyHandle()); // <---- 
    return db;
  }

Contrast that with TtlDB.java's open method that accepts an Option:

  public static TtlDB open(final Options options, final String db_path,
      final int ttl, final boolean readOnly) throws RocksDBException {
    return new TtlDB(open(options.nativeHandle_, db_path, ttl, readOnly));
  }

Steps to reproduce the behavior

Instead of a RocksDb, configure a TtlDB with Options and try using an iterator.

[dtanner]

I'm happy to submit a PR that configures the default column family handle in TtlDB, but maybe there's a good reason it behaves differently?

[alanpaxton]

Thank you @dtanner - I think it's just a straightforward error on our part; I'll see if I can organise a fix just now..

[alanpaxton]

FYI @dtanner this was fixed in the PR #12167 - are you using the most recent released version of rocksdbjni ?

[alanpaxton]

And of course it turns out that there are related issues in other RocksDB subclasses, plus a lot of inconsistency . I have addressed these in #12417