这是indexloc提供的服务,不要输入任何密码
Skip to content

Update Rust SDK and add NDC v0.1.2 support #42

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 2 commits into from
Apr 17, 2024
Merged

Conversation

daniel-chambers
Copy link
Contributor

@daniel-chambers daniel-chambers commented Apr 17, 2024

This PR updates the Rust SDK to a newer version which brings support for NDC spec v0.1.2. It then updates the connector to support the new Type Representations that were added in v0.1.2.

NDC scalar types are now generated using separate code instead of translating them from v2 scalar types. This is because v2 scalar types don't contain enough information to determine what the type representation should be.
However, the comparison operators and aggregate operators (the most complex bits) are drawn from the same code as v2.

I also did a bit of refactoring and moved some of the properties such as "orderable" and "comparable" onto the BsonScalarType object instance. I implemented it using a flat match expression rather than the existing "look in an array" method, because, while that might make for shorter code, the flat match expression will produce compiler errors if the BSON type ever changes.

JIRA: MDB-88

@daniel-chambers daniel-chambers self-assigned this Apr 17, 2024
S::BinData => false,
S::ObjectId => false,
S::Bool => false,
S::Null => false,
Copy link
Contributor

Choose a reason for hiding this comment

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

In MongoDB values of any type can be compared and ordered. I get that we may want to be a bit stricter on what we allow, but a few of these I'm not sure about:

  • Given ObjectId is the type of the primary key in most collections, it might be useful to be orderable. Although I'm not really sure.
  • Bool ordering is by convention (and by the rules of Boolean Algebra) usually defined with false < true. But maybe that's not useful in a database. What do other connectors do?
  • Null is trivially orderable as the type has exactly one value (null). But again, I'm not sure if that's practically useful.

@hallettj do you have any thoughts on this?

Copy link
Contributor

Choose a reason for hiding this comment

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

@daniel-chambers given that you have just kept the same behaviour as previously, with respect to ordering and comparison, I don't think we need to let any debate on this hold up this PR. Your changes look good so I'll approve it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair points. I agree with ordering for ObjectId and Bool, sure. I wouldn't bother with null; we'd just be adding complexity to their GraphQL types for no reason.

@daniel-chambers daniel-chambers merged commit 2931b2c into main Apr 17, 2024
@daniel-chambers daniel-chambers deleted the daniel/ndc-0.1.2 branch April 17, 2024 12:38
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.

2 participants