-
Type:
New Feature
-
Resolution: Fixed
-
Priority:
Unknown
-
Affects Version/s: None
-
Component/s: BSON
Use Case
As a... consumer of the BSON package
I want... _bsontype to be available under a symbol property
So that... there are no conflicts with user-provided _bsontype methods
User Experience
- value[bsonType] should be the same as value._bsontype for BSONValue subclasses, but should not be defined for deserialized objects with a _bsontype property
Dependencies
- This simplifies code which relies on detecting arbitrary BSON types in downstream dependencies (DevTools, Atlas Streams Processing)
Risks/Unknowns
- What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
- Is there an opportunity for better cross-driver alignment or testing in this area?
- Is there an opportunity to improve existing documentation on this subject?
Acceptance Criteria
Implementation Requirements
- functional reqs, potential snafus to avoid, performance targets, etc
Testing Requirements
- unit test, spec test sync, etc
Documentation Requirements
- DOCSP ticket, API docs, etc
Follow Up Requirements
- additional tickets to file, required releases, etc
- if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward
- related to
-
NODE-5144 Add static BSONValue.isX cross vm context instance of check methods
-
- Backlog
-