-
Notifications
You must be signed in to change notification settings - Fork 266
PHPLIB-675 Add helpers to check collection types to CollectionInfo #839
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
Show all changes
3 commits
Select commit
Hold shift + click to select a range
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
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
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.
For a moment, let's ignore the capped method we already have. Based on https://docs.mongodb.com/manual/reference/command/listCollections/#mongodb-data-listCollections.cursor, would it make more sense to just create getters for the missing top-level fields?
These three methods could be replaced with
getType() : string
. Additionally, we could introducegetInfo() : array
for theinfo
field, which would presumably cast likegetOptions
does. I would be a bit concerned that "info" there might confuse users into thinking it returns the entire IndexInfo object as an array -- so I'm open to ways we can avoid the misunderstanding.I have no idea what
idIndex
actually looks like, but I wonder if that'd be problematic to cast to an array as well.While this class does implement ArrayAccess, I don't think it's easy to know exactly what can be accessed. It'd be lousy to call
__debugInfo()
directly, but that basically returns the value someone might want to have full access. I'm open to other ideas to make this most accessible.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 was considering this as well. I'm thinking this:
I'm not sure what to do with the
isCapped
helper though, whether to keep or deprecate it.A different, more involved approach, would see different classes for the various types exposed through CollectionInfo:
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.
Giving this some more though: If I knew nothing about this class, I think my first impression of
getRawInfo
would be the method that returns everything (like__debugInfo
). I thinkgetInfo
makes more sense and we can just clearly document that it returns the "info" property of the server response.I think we can deprecate it in documentation. That would give us something to point to if an idea for other specific helpers comes up down the line.
While that would be very usable (folks could use
instanceof
), I don't think we have the data to invest in this API -- and that's basically taking us down a road of query builders where we'd need to maintain this for each server update. Perhaps worse because I don't think the server response is fully documented.This does seem like something more fitting for an auxiliary library (PHPLIB-4), which is where we originally intended to build out APIs for other shell-like commands (e.g. user management, misc. helpers).
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.
Good point. I've added getters for
idIndex
,info
, andtype
which previously didn't have any. I also added@deprecated
phpdoc comments to theisCapped
,getCappedMax
, andgetCappedSize
methods, but they don't trigger any deprecations warnings yet.