-
Notifications
You must be signed in to change notification settings - Fork 534
RUBY-3087 reinstate ability to call insert_many with Enumerable inputs which are not Array instances #2594
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
RUBY-3087 reinstate ability to call insert_many with Enumerable inputs which are not Array instances #2594
Conversation
|
Hi @midnight-wonderer, and thanks for submitting this PR! We will review this and get back to you with any feedback. |
|
It already breaks D: (test failed) |
|
Updated! The user should be responsible for side effects that may occur because of multiple I would like to suggest subclassing |
|
Hey @midnight-wonderer thanks for the ping! I just added another test, and some docs stating that we now support enumerables in the respective methods. Would you mind taking a look at that? |
|
LGTM (Neil's commit) |
docs/release-notes.txt
Outdated
| - When 0 is given as the max connection pool size, it is now interpreted to | ||
| mean no limit. | ||
| - The default maximum connection pool size has been increased to 20 from 5. | ||
| - Added support for enumerables in bulk write operations. |
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.
If we are fixing this let's backport the fix to 2.18-stable and then it won't need a release note here.
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.
Why won't it need a release not even if we're backporting to 2.18?
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 the break was in 2.18, thus after the fix there wouldn't be any stable branch where the issue exists so it might be confusing to people to try to work out which versions are broken.
But if you wish to have the note, that's fine, I would just phrase it as "Reinstated support for enumerables" or similar since it was already present and unintentionally broken.
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.
oh okay I will remove it
lib/mongo/collection.rb
Outdated
| # collection.insert_many([{ name: 'test' }]) | ||
| # | ||
| # @param [ Array<Hash> ] documents The documents to insert. | ||
| # @param [ Array<Hash>, Enumerable ] documents The documents to insert. |
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.
| # @param [ Array<Hash>, Enumerable ] documents The documents to insert. | |
| # @param [ Array<Hash>, Enumerable<Hash> ] documents The documents to insert. |
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.
That would be correct yes?
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 don't use type in Ruby, so I don't know which one can be generic.
However, if Enumerable can be generic too and Array is also an Enumerable, we can also just do Enumerable<Hash>.
There are three possibilities forward:
Array<Hash>, Enumerableas Neil suggested
probably maybe becauseEnumerableis not a generic type? And also not to confuse developers that are new to the concept of Ruby's module.Array<Hash>, Enumerable<Hash>as you suggested
becauseEnumerableis actually a generic type; leaving theArraytype as is for the same reason as above.Enumerable<Hash>
ifEnumerableis a generic type, and we prioritize conciseness.
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 don't have a strong opinion on this, I had just looked for examples elsewhere in the code base and this is what we did. I don't mind switching it...
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 think Array<Hash> | Enumerable<Hash> is redundant, my vote is for Enumerable<Hash> only.
@midnight-wonderer This notation simply signifies the expected type of values in the container, we haven't magically come up with a way to add generics to Ruby :)
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.
That's fine with me
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.
done
|
I resolved the spec description issue mentioned by p-mongo, hope you don't mind; could you take a look at the other comments? @neilshweky |
|
@p-mongo this is rfal |
|
@midnight-wonderer Thank you again for the PR and the fix. |
…s which are not Array instances (#2594) * RUBY-3087 add a test for insert_many with enumerable inputs * RUBY-3087 raise exception on bulk_write without using an Array method * RUBY-3087 add test, docs * add docs, release notes * Fix the description of empty bulk_write spec to match the behavior * Update docs/release-notes.txt * change docstrings to use enumerables Co-authored-by: Neil Shweky <neilshweky@gmail.com>
Hello,
As I mentioned on #2430, we use
insert_manywith an enumerable instead of an array; we want to make sure it will continue to work into the future.It would be great if you guys could include this test.
I am happy to adjust the pull request as you see fit.