Skip to content

Conversation

@nbbeeken
Copy link
Contributor

https://jira.mongodb.org/browse/SWIFT-754
A more swifty driver with Int dropping the bit width specification in the user API.

@nbbeeken nbbeeken requested review from kmahar and patrickfreed April 20, 2020 19:34
public var max: Document?

/// The maximum amount of time for the server to wait on new documents to satisfy a tailable cursor
/// query. This only applies when used with `CursorType.tailableAwait`. Otherwise, this option is ignored.
Copy link
Contributor

Choose a reason for hiding this comment

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

while you are here, how about updating this to "The maximum amount of time, in milliseconds, for the server..."? (same for similar time based MS options you've updated). most people probably know what MS are but I think it would be good to clarify.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do we have a way of logging a warning? but I agree its acceptable and pure swift is on the horizon which would make this a non-issue.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think you maybe posted this in reply to the wrong comment?

In any case we don't have logging right now, but you can put a TODO SWIFT-349 saying to log something when we add it

Copy link
Contributor Author

@nbbeeken nbbeeken Apr 22, 2020

Choose a reason for hiding this comment

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

Um yea that was meant for mongoc_apm_command_succeeded_get_duration.... not sure how that happened sounds good 👍

switch self {
case let .number(wNumber):
try container.encode(wNumber)
try container.encode(Int32(wNumber))
Copy link
Contributor

Choose a reason for hiding this comment

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

since this method already throws anyway, we could consider throwing an error here if the value is too large to cast to an Int32. it's unlikely anyone will ever hit the error case but it's a little safer than the cast which could technically fail.
you could use the Int32(exactly:) initializer to test this safely, which returns nil if the value can't be represented exactly as an Int32.

also, let's add a comment here clarifying we do this because libmongoc requires it. then when we aren't wrapping libmongoc anymore we will know we can stop doing the cast.


fileprivate init(mongocEvent: MongocCommandSucceededEvent) {
self.duration = mongoc_apm_command_succeeded_get_duration(mongocEvent.ptr)
self.duration = Int(mongoc_apm_command_succeeded_get_duration(mongocEvent.ptr))
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess technically this can fail if we're on a 32 bit system and a command lasts longer than 35 minutes... probably not gonna happen though

internal init(_ description: OpaquePointer) {
self.address = Address(mongoc_server_description_host(description))
self.roundTripTime = mongoc_server_description_round_trip_time(description)
self.roundTripTime = Int(mongoc_server_description_round_trip_time(description))
Copy link
Contributor

Choose a reason for hiding this comment

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

similar to the command duration one this seems ok too... this one is even less likely to be an issue because it's milliseconds rather than microseconds

try container.encode(wNumber)
} else {
throw InvalidArgumentError(
message: "Invalid WriteConcern.w \(wNumber): must be between \(Int32.min) and \(Int32.max)"
Copy link
Contributor

Choose a reason for hiding this comment

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

the number actually has to be >= 0

@nbbeeken nbbeeken merged commit 940d90d into master Apr 23, 2020
@nbbeeken nbbeeken deleted the SWIFT-754/useInt branch April 23, 2020 19:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants