I don't like where this goes. While adding capability & configurability is nice, exposing more APIs reduces future extendability.

Whilst I see why this feature might be useful in some scenarios, I would like to encourage people to use databases as is and if you need custom behavior wrap them on another layer. It doesn't matter whether you're using hive or any other database or any system in general.

I'm not going to nor approve or reject the proposed changes. I would like to hear what others think about this.

Personally I think this is a great idea! Is very usefull for example when you want the UI to change only in specific scenarios, with this simple change we can save lot of lines of code to achive the same externaly.

@themisir I'm interested in knowing in which cases this would reduce "future extendability". Could you elaborate and exemplify?

I'm interested in knowing in which cases this would reduce "future extendability".

I dunno, if there's any, we'll see in future. Planning is one of the core pillars of software lifecycle, and limiting public scope allows software to be extended in future without breaking its user facing API.

A possible issue this might cause is if dart in future gets proper multithreading implementation we can in theory move hive backend to run on separate thread and provide multi isolate support, but watch-ability might cause some issues when implementing that.

However I don't think dart is going to get proper threading support anytime soon nor I'm interested in adding more features to hive (because isar is far more superior currently, or for more complex use cases SQLite been there for years). So if community demands this feature, let's merge it.

@themisir any updates on when this will be released?