Skip to content
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

feat(parse)!: add proto::extensions::SimpleExtensionUri parser #169

Merged
merged 3 commits into from
Apr 3, 2024

Conversation

mbrobbel
Copy link
Member

@mbrobbel mbrobbel commented Apr 2, 2024

Adds a parser for proto::extensions::SimpleExtensionUri that parses the uri and adds the extension to the parse context.

Breaking change because the parse Context trait gets two new functions to support this:

  • add_simple_extension_uri: this is used to add a simple extensions, the parse context must directly resolve the uri and return the parsed simple extensions - struct stub for that is added in this PR (the parser is TODO).
  • simple_extensions: given an reference (anchor) to a simple extensions - check if this was added to the parse context and return it

@mbrobbel mbrobbel mentioned this pull request Apr 2, 2024
32 tasks
src/parse/context.rs Outdated Show resolved Hide resolved
Entry::Vacant(entry) => {
// This is where we would resolve and then parse.
// This check shows the use of the unsupported uri error.
if let "http" | "https" | "file" = simple_extension_uri.uri().scheme() {
Copy link
Member

Choose a reason for hiding this comment

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

Some dialects do not require or expect a scheme (I'll get examples when I return from vacation). It may be useful to make this configurable.

Copy link
Member Author

Choose a reason for hiding this comment

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

That should be documented here: https://github.com/substrait-io/substrait/blob/e564cf0b3b769491c19016d92d195b5f62361775/proto/substrait/extensions/extensions.proto#L18-L20

Please note that this is just a test context, and not the actual context that I want to eventually provide in this crate. In that case yes, the resolver should be configurable.

Enjoy your vacation!


/// A parsed [proto::extensions::SimpleExtensionUri].
#[derive(Clone, Debug, PartialEq)]
pub struct SimpleExtensionUri {
Copy link
Member

Choose a reason for hiding this comment

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

A builder is going to need to do registration (not that you need that now).

Copy link
Member Author

Choose a reason for hiding this comment

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

What do you mean with registration? The approach taken here is to have the parse context resolve, fetch and parse the referred extension (when parsing the definition):

// Make sure the URI is supported by this parse context, resolves and
// parses, and the anchor is unique.
ctx.add_simple_extension_uri(&simple_extension_uri)?;

Copy link
Member

Choose a reason for hiding this comment

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

If an instance of this is created through the course of creating a plan (not the parse case you're concentrating on at the moment) the registration of anchors/reference ids would be handy. It may happen in another class that generates these (perhaps providing function lookup and SQL to Substrait lookup). I will be fleshing out a builder in substrait-python soon.
A builder (and registration) isn't a concern for this PR.

@mbrobbel mbrobbel merged commit 332d607 into substrait-io:main Apr 3, 2024
11 checks passed
@mbrobbel mbrobbel deleted the parse/simple_extension_uri branch April 3, 2024 08:27
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