-
Notifications
You must be signed in to change notification settings - Fork 67
SWIFT-411 Make pointer access to bson_ts more explicit #264
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
it occurred to me as I made these changes that we are kind of doing the same bad thing here where we are mutating this
bson_t. but maybe it's overkill to do some kind ofwithPointerfor the storage, too.similar to
DocumentIterator,DocumentStoragecould probably use some rethinking...Uh oh!
There was an error while loading. Please reload this page.
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.
Hmm. It's making me think we should just make
DocumentStorageaprivatetype (not eveninternal) and update all the public or non-Documentstuff that uses it just take aDocumentinstead. It seems too dangerous to circumvent the api you're adding toDocumentin this PR to warrant exposing the storage, even at theinternallevel.Uh oh!
There was an error while loading. Please reload this page.
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 considered that.... it seems like it might confuse users that there would be this public method on
BSONValue:encode(to: Document, forKey key: String)but that we don't actually intend for them to set values on documents that way....
then again, this existence of that method and
DocumentStoragein the public API are already confusing as it is.I wonder if
DocumentStorageshould get a bunch of methods on it:appendInt32,appendString, and so on... and then we type switch withinDocument(or in some genericappendBSONValuemethod onDocumentStorage) to decide which method to call?that brings us back to same problem where
BSONValueis a protocol but people can't really actually make arbitrary types conform to it since we wouldn't be switching on them there...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.
Because we call
copyStorageIfRequiredwhere necessary insetValueand we've updated thecountproperty, the bad things we're doing here aren't resulting in any buggy behavior (I think). It would be preferable to guarantee that at the mutating call's site, but without big changes that'll be hard to do for the reasons you mention.As far as big changes go though, I have a fun idea...
We would update
DocumentStorageto be a wrapper around an internalDatabuffer that we manage ourselves instead of abson_t. We'd then update theBSONValueprotocol to require abson: Dataproperty (or something like that) that emits a buffer containing the raw BSON bytes (and removeencode(to:forKey). Then, where we normally callencode, we instead get this buffer from theBSONValueand append it to our internal buffer (with the necessary bookkeeping for keys, types, etc). When we do need abson_t, we can usebson_init_staticto create a lightweight, read-only, and stack allocatedbson_tfrom the internal buffer.This gets us like 99% of the way to pure Swift BSON, avoids a lot of memory issues, and makes the
BSONValueprotocol more sensical. This is obviously out of scope for this ticket, but I think it could be a good approach for solving issues we have now as well as moving towards a pure Swift driver.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.
ha, when I started thinking about the pure Swift BSON library design I came up with something very similar where we would have a
bytesproperty onBSONValue🙂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.
Makes me realize that pure swift BSON library may actually be a breaking change, so we might have to do it pre-GA 🤔
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.
Yeah I think we discussed this some time ago. This is what the C++ driver does, rather than keeping instances of
bson_teverywhere.bson_tinitialization isn't zero overhead, but it might not be that bad. I'd say go ahead and make a ticket for the featureThere 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.
Filed SWIFT-497