Skip to content
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

Merged
merged 21 commits into from
Apr 25, 2023
Merged

Added core logging #5727

merged 21 commits into from
Apr 25, 2023

Conversation

papafe
Copy link
Contributor

@papafe papafe commented Apr 13, 2023

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

@cla-bot cla-bot bot added the cla: yes label Apr 13, 2023
* 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
papafe and others added 7 commits April 17, 2023 15:15
* main:
  Update core to v13.9.1 (#5739)
  Implement `User.state` (#5712)
  Rename `local-mongodb` to enable app replacements (#5734)
  Update return type of 'assert.never'. (#5718)
  Run tests after builds are done, regardless of they failed or succeeded (#5729)
@papafe papafe marked this pull request as ready for review April 18, 2023 14:22
Copy link
Contributor

@elle-j elle-j left a 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 👍

integration-tests/tests/src/tests/shared-realms.ts Outdated Show resolved Hide resolved
Comment on lines +61 to +67
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;
Copy link
Contributor

@elle-j elle-j Apr 18, 2023

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?

Copy link
Contributor Author

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 😁

Copy link
Contributor

@elle-j elle-j Apr 19, 2023

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 Show resolved Hide resolved
packages/realm/src/Logger.ts Show resolved Hide resolved
Comment on lines 73 to 74
const consoleErrorLevels: LogLevel[] = ["error", "fatal"];
const consoleWarnLevels: LogLevel[] = ["warn"];
Copy link
Contributor

@elle-j elle-j Apr 18, 2023

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.

Suggested change
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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or perhaps satisfies WarnLogLevel[].

Suggested change
const consoleErrorLevels: LogLevel[] = ["error", "fatal"];
const consoleWarnLevels: LogLevel[] = ["warn"];
const consoleErrorLevels = ["error", "fatal"] satisfies LogLevel[];
const consoleWarnLevels = ["warn"] satisfies LogLevel[];

Copy link
Contributor Author

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.

packages/realm/src/Logger.ts Show resolved Hide resolved
packages/realm/src/app-services/Sync.ts Outdated Show resolved Hide resolved
packages/realm/src/app-services/Sync.ts Outdated Show resolved Hide resolved

const inverseTranslationTable: Record<LogLevel, binding.LoggerLevel> = Object.fromEntries(
Object.entries(translationTable).map(([key, val]) => [val, Number(key)]),
) as unknown as Record<LogLevel, binding.LoggerLevel>;
Copy link
Member

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.

Copy link
Contributor Author

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)
{
Copy link
Contributor Author

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.

packages/realm/src/Logger.ts Show resolved Hide resolved
* main:
  Added note in docs for change listeners (#5749)
  Update CHANGELOG entry (#5751)
  Use `SchemaParseError` for invalid schemas (#5722)
  Improving Electron tests (#5738)
  Support SSL Sync Configuration (#5507)

# Conflicts:
#	CHANGELOG.md
* 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)
@papafe papafe merged commit b3a19af into main Apr 25, 2023
@papafe papafe deleted the fp/core-logging branch April 25, 2023 10:42
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support Core logging
4 participants