Skip to content

Conversation

prestonvasquez
Copy link
Member

WRITING-26459

Summary

Add the v2 migration guide to docs

Background & Motivation

@prestonvasquez prestonvasquez changed the base branch from v1 to master August 22, 2024 22:25
@prestonvasquez prestonvasquez requested a review from jtazin August 22, 2024 22:45
@jtazin jtazin requested a review from rustagir August 23, 2024 16:38
Copy link
Contributor

@jtazin jtazin left a comment

Choose a reason for hiding this comment

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

A few formatting suggestions

- `UnmarshalExtJSONWithRegistry`
- `UnmarshalExtJSONWithContext`

For example, a boolean type can be stored in the database as a BSON boolean, int32, or int64. Given a registry:
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
For example, a boolean type can be stored in the database as a BSON boolean, int32, or int64. Given a registry:
For example, a boolean type can be stored in the database as a BSON `Boolean`, `Int32`, or `Int64`. Given a registry:

Copy link
Member Author

Choose a reason for hiding this comment

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

Go native types are not capitalized.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I regard "boolean", "in32", "int64", or "true" are general concepts, that don't need to be denoted.

Copy link
Contributor

Choose a reason for hiding this comment

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

@prestonvasquez isn't this specifically talking about the BSON types rather than the native types? This suggestion was based on the code sample below which has bsontype.Boolean, bsontype.Int32, and bsontype.Int64

Copy link
Member Author

Choose a reason for hiding this comment

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

BSON type references should also not be capitalized.

I think we should either leave them as-is or reference the package type, as you suggest (i.e. bsontype.Boolean).

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, I'll defer to your judgement here. I noticed that it was capitalized in the code sample, which is why I suggested it, but if it doesn't make sense, let's keep it as-is. Feel free to resolve this one :)

Copy link
Member Author

Choose a reason for hiding this comment

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

I've updated the guide to use phrasing from the BSON specifications.

bsoncodec.ValueDecoderFunc(lenientBoolDecoder))
```

For our custom decoder with such a registry, BSON int32 or int64 values are considered "true" if they are non-zero.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
For our custom decoder with such a registry, BSON int32 or int64 values are considered "true" if they are non-zero.
For our custom decoder with such a registry, BSON `Int32` or `Int64` values are considered `true` if they are non-zero.

Copy link
Contributor

Choose a reason for hiding this comment

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

We can keep the int32 and int64 lowercase as discussed in the previous thread.
But I'm guessing we should remove the quotation around "true" though. It's probably best to format it as code (based off of the convention I'm noticing in the rest of the doc when it comes to values, for example "to differentiate between an ID of 0 and no ID").


### ValueMarshaler

The `MarshalBSONValue` method of the `ValueMarshaler` interface is only required to return a byte type value representing the BSON type to avoid importing the Go driver package.
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the name of the package that no longer needs to be imported?

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

I've updated at 60af8e3

@mongodb-drivers-pr-bot mongodb-drivers-pr-bot bot added the documentation Pull requests that update documentation or examples label Aug 23, 2024
@mongodb-drivers-pr-bot mongodb-drivers-pr-bot bot added the review-priority-low Low Priority PR for Review: within 3 business days label Aug 23, 2024
qingyang-hu
qingyang-hu previously approved these changes Aug 27, 2024
Copy link
Contributor

@rustagir rustagir left a comment

Choose a reason for hiding this comment

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

looks good, I still suggest standardizing the way different code components (methods/types/etc) are displayed, but it is a low priority and users should understand

Comment on lines +432 to +448
```go
client, err := mongo.NewClient(options.Client())
if err != nil {
log.Fatalf("failed to create client: %v", err)
}

if err := client.Connect(context.TODO()); err != nil {
log.Fatalf("failed to connect to server: %v", err)
}
```

```go
client, err := mongo.Connect(options.Client())
if err != nil {
log.Fatalf("failed to connect to server: %v", err)
}
```
Copy link
Contributor

Choose a reason for hiding this comment

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

S: add the v1 and v2 code comments for clarity

@blink1073 blink1073 added review-priority-normal Medium Priority PR for Review: within 1 business day and removed review-priority-low Low Priority PR for Review: within 3 business days labels Aug 29, 2024
@jtazin
Copy link
Contributor

jtazin commented Aug 30, 2024

looks good, I still suggest standardizing the way different code components (methods/types/etc) are displayed, but it is a low priority and users should understand

@rustagir agreed, do you have any specific suggestions on how to do that?

@rustagir
Copy link
Contributor

rustagir commented Sep 3, 2024

Re: #1766 (comment)

In the docs we usually follow the convention to identify code components eg.

  • You can use the x() method to ...
  • Pass an instance of y to the z() method to...
  • The w interface provides...

And so on. But I am leaving this as an optional formatting suggestion for the team.

Copy link
Contributor

API Change Report

No changes found!

@prestonvasquez prestonvasquez merged commit 75e02b2 into mongodb:master Sep 4, 2024
3 of 5 checks passed
@prestonvasquez prestonvasquez deleted the WRITING-26459 branch September 4, 2024 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Pull requests that update documentation or examples review-priority-normal Medium Priority PR for Review: within 1 business day

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants