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

(DOCSP-39541) Consolidate logging page #3273

Merged

Conversation

krollins-mdb
Copy link
Collaborator

@krollins-mdb krollins-mdb commented May 23, 2024

Pull Request Info - SDK Docs Consolidation

Jira ticket: https://jira.mongodb.org/browse/DOCSP-39541

Staged Page

Page Source

Add links to every SDK's pages where you got the SDK-specific information:

PR Author Checklist

Before requesting a review for your PR, please check these items:

  • Open the PR against the feature-consolidated-sdk-docs branch instead of master
  • Tag the consolidated page for:
    • genre
    • meta.keywords
    • meta.description

Naming

Links and Refs

  • Create new consolidated SDK ref targets starting with "_sdks-" for relevant sections
  • Remove or update any SDK-specific refs to use the new consolidated SDK ref targets
  • Update any Kotlin API links to use the new Kotlin SDK roles

Content

  • Shared code boxes have snippets or placeholders for all 9 languages
  • API description sections have API details or a generic placeholder for all 9 languages
  • Check related pages for relevant content to include
  • Create a ticket for missing examples in each relevant SDK: Consolidation Gaps epic

Reviewer Checklist

As a reviewer, please check these items:

  • Shared code example boxes contain language-specific snippets or placeholders for every language
  • API reference details contain working API reference links or generic content
  • Realm naming/language has been updated
  • All relevant content from individual SDK pages is present on the consolidated page

@krollins-mdb krollins-mdb added the merge to feature branch Unreleased feature - do not merge to Master label May 23, 2024
@krollins-mdb krollins-mdb changed the title Docsp 39541 (DOCSP-39541) Consolidate logging page May 23, 2024
Copy link

github-actions bot commented May 23, 2024

Readability for Commit Hash: d9296e5

You can see any previous Readability scores (if they exist) by looking
at the comment's history.

Readability scores for changed documents:

  • source/sdk/test-and-debug/log: Grade Level: 7.1, Reading Ease: 66.84

For Grade Level, aim for 8 or below.

For Reading Ease scores, aim for 60 or above:

Score Difficulty
90-100 Very Easy
80-89 Easy
70-79 Fairly Easy
60-69 Medium
50-59 Fairly Hard
30-49 Hard
0-29 Very Hard

For help improving readability, try Hemingway App.

@krollins-mdb krollins-mdb marked this pull request as ready for review June 6, 2024 17:17
RealmInternal.logMessageForTesting(RealmLogLevel.trace,
"This message should be logged because the log level was changed");
// Hack to wait for stream to process
await delay(200);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is a bit of a hack to wait for the stream to and listeners to do their thing.

I would love to make this code a more realistic use case and incorporate it into a Flutter app, but there's no time for that - especially as part of the consolidation project.

Copy link
Collaborator

@dacharyc dacharyc left a comment

Choose a reason for hiding this comment

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

This is a great start! There are some things that come across kind of weird on on the consolidated page that I think we can improve, and there are some updates we should make to the metadata.

source/sdk/test-and-debug/log.txt Outdated Show resolved Hide resolved
source/sdk/test-and-debug/log.txt Outdated Show resolved Hide resolved

.. include:: /includes/sdk-examples/logger/logging-turn-off-example.rst

Java SDK: Deprecated Sync Logger
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think, instead of having two separate "Deprecated Sync Logger" sections for different SDKs, I'd probably rename this generically to:

"Deprecated Sync Logger"

And then use a tab group here to display the C++ and Java info.

For the tabs that aren't C++ or Java, I'd probably add a quick note saying something like:

The SDK deprecated the Sync logger in favor of the Realm logger in version . For versions and earlier, refer to the for details about the deprecated APIs.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I renamed the section to "Other Loggers" and have just two tabs: C++ and Java. I did this because, as you say, the Java logger isn't really the same thing as the deprecated Sync Logger. But the C++ SDK currently needs that Sync Logger. So, they're both different from the rest of the examples on the page.

Java SDK: Deprecated Sync Logger
--------------------------------

The Java SDK's only logger is a deprecated sync logger that behaves differently
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure this is technically true? The RealmLogger in Java doesn't say anything about being restricted to a Sync logger - it's not in the Sync package, and the API reference docs say:

Global logger used by all Realm components. Custom loggers can be added by registering classes implementing RealmLogger.

So - I think this can be used similar to the other loggers, and it just doesn't have any examples other than setting the log level.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, I didn't frame this correctly. Thanks!


.. _cpp-set-the-client-log-level:

Set the Sync Client Log Level
Copy link
Collaborator

Choose a reason for hiding this comment

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

We probably don't need a separate subheader here. It's taking more real estate/attention than I think it needs in the OtP. And if we make this a generic "Deprecated Sync Logger" header with tab groups for SDK-specific info, then I think we wouldn't want this header to show on the page anyway since it would only be in the C++ tab.


.. include:: /includes/sdk-examples/logger/logging-set-custom-logger-example.rst

After setting a custom logger, you may need to initialize the logger.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This reads a bit weird to me on languages where there is no example of initializing the logger. For example, on C#, there's a "missing example" placeholder below this copy. I wasn't sure if that's because the example is actually missing, or if you don't have to do a separate step of initializing the logger, since the copy here says "you may need to."

I think I would probably move this content for SDKs that require it up into the tab group above, and just omit it from here.

Then, I would include the "last" code example as the code example in the /includes/sdk-examples/logger/logging-set-custom-logger-example.rst file.

For example, for C++ - I see there's an example of initializing the logger below. I would make that the example in the /includes/sdk-examples/logger/logging-set-custom-logger-example.rst file, and then move the C++ example of actually defining the custom logger into the /includes/api-details/cpp/logger/logging-customize-logger-description.rst file.

Let me know if this makes sense or if you have Qs!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmm, yeah. I went back and forth trying to figure out how much structure to impose. Including initialization as an include in the SDK description hides the expected structure a bit (set -> initialize). But doing the way I currently am definitely makes it awkward for a couple of the SDKs.

@@ -1,4 +1,3 @@
.. _ios-init-appclient:
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should probably omit this file from the PR so we're not getting into merge conflicts in the temp directory.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ah, right. I think I had a build error about ambiguous refs, so deleted this one. Before I realized the right way is to use the consolidated refs.

@@ -1,3 +1,4 @@
.. _ios-init-appclient:
Copy link
Collaborator

Choose a reason for hiding this comment

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

One of the units of work for this project is to remove SDK-specific ref targets, so we shouldn't add this here. We should just use the generic sdks-connect-to-atlas ref target if we need to link to this page.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmm. Yeah, I can't remember why I added it here. It's not used anywhere in the consolidated content. 🤷

Thanks for catching this!

- MacOS logs to NSLog.
- iOS logs to NSLog.

.. include:: /includes/tip-sync-log-levels.rst
Copy link
Collaborator

Choose a reason for hiding this comment

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

One of the benefits of consolidating the docs pages is that we generally shouldn't need generic includes, because we don't need to split content across a bunch of pages. Instead of nesting this includes here, I'd try taking the content out of the include and putting it directly on the main page wherever it needs to be.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks for catching that. I do have this on the main page already. 😄

Copy link
Collaborator

@dacharyc dacharyc left a comment

Choose a reason for hiding this comment

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

Just to avoid blocking this, changing my review status from "request changes" to "comment."

@dacharyc dacharyc self-requested a review June 6, 2024 19:57
Copy link
Collaborator

@dacharyc dacharyc left a comment

Choose a reason for hiding this comment

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

Trying again to change the review state to "comment" just so I don't block this while I'm out next week.

@krollins-mdb krollins-mdb requested a review from dacharyc June 17, 2024 18:21
Copy link
Collaborator

@dacharyc dacharyc left a comment

Choose a reason for hiding this comment

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

Looking good! Just a couple of things with tab IDs, and I think we need to add some generic placeholder content to the "Other Loggers" section for languages other than C++ or Java or else it looks like the page is missing text for that section.


.. include:: /includes/sdk-examples/logger/logging-turn-off-example.rst

Other Loggers
Copy link
Collaborator

Choose a reason for hiding this comment

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

lol, I didn't think about this, but for languages other than C++ or C#, this section header now shows with no content. (i.e. Kotlin has an "Other Loggers" heading with no content.) I guess in this case, we should add something to the tabs. Maybe this would be a place to mention the deprecated Sync logger? i.e.

In SDK versions {FOO} and earlier, you could configure a Sync logger using methodName. That method has been deprecated in favor of the global logger.

One for each SDK with the version number in which the Sync logger was deprecated, and the Sync logger method name. I'd say we should avoid linking to the deprecated Sync logger API reference, because at some point those links will break. But it may be useful for folks using the older methods, if nothing else than to have the method name show up if they do a search in the docs so they can see it has been deprecated.

Copy link
Collaborator Author

@krollins-mdb krollins-mdb Jun 25, 2024

Choose a reason for hiding this comment

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

In addition to the comment below about Java content, this seems like a lot of effort and complexity for two minor, relatively unsupported, things. I think I'm going to go back to dedicated sections, but have them be under "Other Loggers".

source/sdk/test-and-debug/log.txt Outdated Show resolved Hide resolved
source/sdk/test-and-debug/log.txt Outdated Show resolved Hide resolved
source/sdk/test-and-debug/log.txt Outdated Show resolved Hide resolved
.. tab::
:tabid: csharp

The Java SDK uses an older Logger that may not behave like the other SDKs.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This content is in a csharp tab (maybe it was copied from above?), but it pertains to the Java SDK. We'll need to update this ID to java for this info, which means we'll have to add it to all of the tab sets on the page and the ones in the includes/sdk-examples/logger or we'll get Snooty errors about a missing tab. But since we don't have Java content that is relevant for those other sections, you'll have to use your judgement about what to put there. Maybe the missing API snippet for the code blocks, and I don't know if it's relevant to add text copy for each Java tab saying that the Java SDK uses a separate logger described below, or if we can just let the missing API snippet serve in those sections.

@krollins-mdb krollins-mdb requested a review from dacharyc June 25, 2024 00:49
Copy link
Collaborator

@dacharyc dacharyc left a comment

Choose a reason for hiding this comment

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

Nice work! I know this has been a big rethink about how the docs work versus the old way. I've got just a few more minor comments, but those are more subjective and not blockers. Thanks for all your effort on this!

amounts of data depending on your development needs. You can specify
different log levels or custom loggers.

.. warning:: Java SDK Logging Support
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't love this bright red warning tab at the beginning of the page for an SDK we don't particularly want people to use. I think we should remove this warning block. It's not relevant if I'm here for any of the languages that we do support. There's a ToC entry in the OTP about Java SDK, so if I'm confused about why Java isn't in the language selector, I can just jump right to that section.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Makes sense to me! Should be a better experience without that warning.

Java SDK
~~~~~~~~

The Java SDK uses an older Logger that may not behave like the other SDKs.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just a general Q - should we be more specific about how this logger differs from the other SDKs?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe. But I don't think it's worth spending more time on. I think I added this sentence to make it clear that the Java SDK wasn't using the same logger type as the other SDKs. But that's accomplished by putting it in the new "Other Loggers" section. I've removed this sentence as it doesn't add anything now and only invites questions. 😄

The SDK logs events to the Android system log automatically. You can
view these events using :android:`Logcat </studio/debug/am-logcat>`.

To access newer logging features, use the Kotlin SDK.
Copy link
Collaborator

Choose a reason for hiding this comment

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

And again, if we want to drive people to the Kotlin SDK, should we be more specific about what new features they'll get access to if they use the Kotlin SDK?

- reframe Java SDK content a bit
@krollins-mdb krollins-mdb merged commit 569a50d into mongodb:feature-consolidated-sdk-docs Jun 25, 2024
7 checks passed
@krollins-mdb krollins-mdb deleted the DOCSP-39541 branch June 25, 2024 19:02
@docs-builder-bot
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge to feature branch Unreleased feature - do not merge to Master
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants