Open kraenhansen opened 8 months ago
I don't have any knowledge of the internals of node.js, so apologies if this is a silly question, but wouldn't that just push the problem around? I.e. if I open a Realm file and don't explicitly close it, wouldn't Core keep a captured JS callback for the logger, preventing the process from exiting? Or are we relying on the GC to kick in and eventually collect the Realm instance and free up the callback?
relying on the GC to kick in and eventually collect the Realm instance and free up the callback?
Exactly, GC would free the Realm instance, which would ultimately free the JS function. But even if it did require an explicit Realm#close
(which is expected if any listeners are registered), it'd be much better than what we have now.
We have a similar (though not identical) problem with dart console apps where we added Realm.shutdown method that developers can call at the end of a dart program to allow clean exit of the process. Not sure if that's a path that makes sense for JS as well.
The problem with allowing the SDK to supply loggers for each component is that it moves us further from the goal of having a single globally-available logger (as defined in the first goal of this scope doc) and increases the complexity of Core having to manage multiple logger configuration sources. Not saying that it's impossible or particularly difficult to do, but it's extra complexity and we should weigh that vs the benefits.
Describe your problem or use case
A Node.js process importing the Realm JS SDK currently hangs after completion, because a JS callback is captured as a static when calling
realm::util::Logger::set_default_logger
.Describe the solution you'd like
We'd like to instead pass a
logger
inconfig
when callingSharedRealm::get_shared_realm
, to make thelogger
passed to and owned by the underlyingDB
here: https://github.com/realm/realm-core/blob/4926f59b1dddb6b84568eaf2d9bc8a53c46437de/src/realm/object-store/impl/realm_coordinator.cpp#L474Ideally we'd like to extend this pattern to the
SyncManager
via theSyncClientConfig
, so our users don't have to callset_logger_factory
after construction of the Realm. In its current state it takes a "logger factory", not thelogger
inself. https://github.com/realm/realm-core/blob/4926f59b1dddb6b84568eaf2d9bc8a53c46437de/src/realm/object-store/sync/sync_manager.hpp#L79Additional context
Ideally, from the SDK's point of view, we'd like to just pass in a lambda (
std::function<void(util::Logger::Level, const std::string& message)>
) through the config - instead of a full-fledgedLogger
instance.