-
Notifications
You must be signed in to change notification settings - Fork 577
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added core logging #5727
Added core logging #5727
Conversation
* main: (41 commits) allow useQuery to filter or sort a collection by using a callback (#5513) Fix `realm.create` types and 'requiredProperties' on Realm.Object constructor (#5697) Fix return type of `App.allUsers` (#5708) Removed renamed file Remove console.log Fix README instructions and bump version Bump template versions Update Templates (#5702) Moved "submodules" wireit task to "postinstall" Set up typedoc for realm-react, realm-web (#5709) Prepare for vNext (#5711) Prepare for 12.0.0-alpha.2 (#5707) Build iOS prebuilds in release by default (#5710) Use the event.sender as assignee when preparing release Updated prepare release workflow to print PR url in summary Fixing lint error fix the template app links (#5701) Expose `Sync` as named export (#5705) Enable all tests after bad rebase (#5595) Clear test state flag (#5689) ... # Conflicts: # packages/realm/src/Realm.ts
Co-authored-by: LJ <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great addition! I have some suggestions 👍
Realm.setLogLevel("warn"); | ||
realm.write(() => realm.create("Person", { name: "Alice" })); | ||
expect(logs).to.be.empty; | ||
|
||
Realm.setLogLevel("error"); | ||
realm.write(() => realm.create("Person", { name: "Alice" })); | ||
expect(logs).to.be.empty; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could also be useful to have tests for when we'd expect log output for "warn"
and "error"
(and "fatal"
).
I'm a little torn on whether we should split up some of the tests into dedicated it
tests as well. If we add some more tests for "warn"
etc, having the it
separation may be favorable? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need separate tests, otherwise we are probably verifying that the whole logger works, even at the core level. We just need to be sure the callback is called, and get a confirmation that we can change the log level. I think we can assume that core verified that all the levels work.
Regarding "warn", "error" and so on, I was thinking about it, but it seems that those are actually raised only when using sync (like with a compensating write), and I thought it would have been too much to create a sync test just to verify the logger (also connected to what I've said before). I'm open to change my mind though 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, the main reason for extending "warn"
etc. would be if the tests are intended to test that the logger not only doesn't get fired when it shouldn't, but also that it does when it should. But if that's not within this scope then it might just be a PR for another time 👍
packages/realm/src/Logger.ts
Outdated
const consoleErrorLevels: LogLevel[] = ["error", "fatal"]; | ||
const consoleWarnLevels: LogLevel[] = ["warn"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This suggestion is combined with my previous one if we provide the additional log level helpers.
const consoleErrorLevels: LogLevel[] = ["error", "fatal"]; | |
const consoleWarnLevels: LogLevel[] = ["warn"]; | |
const consoleErrorLevels: ErrorLogLevel[] = ["error", "fatal"]; | |
const consoleWarnLevels: WarnLogLevel[] = ["warn"]; |
In this case, you'd have to change e.g. consoleErrorLevels.includes(logLevel)
to consoleErrorLevels.includes(logLevel as ErrorLogLevel)
, so not sure how beneficial this would be for us internally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or perhaps satisfies WarnLogLevel[]
.
const consoleErrorLevels: LogLevel[] = ["error", "fatal"]; | |
const consoleWarnLevels: LogLevel[] = ["warn"]; | |
const consoleErrorLevels = ["error", "fatal"] satisfies LogLevel[]; | |
const consoleWarnLevels = ["warn"] satisfies LogLevel[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kraenhansen I wrote this as a comment to another related suggestion, but I'm reluctant to go this route (defining WarnLogLevel
and ErrorLogLevel
), because it will make the code more difficult to read, and we won't get much out of it.
Co-authored-by: LJ <[email protected]>
packages/realm/src/Logger.ts
Outdated
|
||
const inverseTranslationTable: Record<LogLevel, binding.LoggerLevel> = Object.fromEntries( | ||
Object.entries(translationTable).map(([key, val]) => [val, Number(key)]), | ||
) as unknown as Record<LogLevel, binding.LoggerLevel>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to iterate on this with you. I think it'd be possible to use the type parameters on the fromEntries
, entries
and map
to achieve this and avoid as unknown
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually discovered that we don't need the unknown
😁
Before I didn't have the conversion to number
, and that was the issue
@@ -194,6 +194,15 @@ struct Helpers { | |||
using LoggerFactory = std::function<std::shared_ptr<util::Logger>(util::Logger::Level)>; | |||
using LogCallback = std::function<void(util::Logger::Level, const std::string& message)>; | |||
static LoggerFactory make_logger_factory(LogCallback&& logger) | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RedBeard0531 I followed your suggestion of creating a make_logger
method that is being used by the older make_logger_factory
method.
I just wanted to ask if it makes sense the way that I've done it.
Co-authored-by: Kræn Hansen <[email protected]>
* main: Update yaml to version 2.2.2 (#5763) Upgraded RN to 0.71.7 for "realm" and "@realm/react" React Native 0.71.4 → 0.71.7 (#5761) Split changelog and compability matrix. Update readme and support. (#5748) fix build scripts for ios and android Removed simple test/example used to bootstrap bindgen project Make bindgen-lib's .eslintrc be freestanding, and copy to js bindgen dir move js_spec.yml out of bindgen-lib Move js-specific TS files out of bindgen-lib change --template arg to be path to source file move packages/bindgen to packages/realm/bindgen/vendor/bindgen-lib rename realm_js_helpers.h to just realm_helpers.h Iterating Android tests (#5746)
This PR adds support for the new core logging feature.
This closes #2546
NOTE: The test could need to be revisited after realm/realm-core#6524 is merged
☑️ ToDos