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

support clickhouse parameterized views #1181

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Lordworms
Copy link

@Lordworms Lordworms commented Mar 15, 2024

Closes #1167

@coveralls
Copy link

coveralls commented Mar 16, 2024

Pull Request Test Coverage Report for Build 8669253871

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 29 of 33 (87.88%) changed or added relevant lines in 4 files are covered.
  • 21 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+0.02%) to 88.089%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/parser/mod.rs 16 20 80.0%
Files with Coverage Reduction New Missed Lines %
src/tokenizer.rs 21 90.37%
Totals Coverage Status
Change from base Build 8622482464: 0.02%
Covered Lines: 21314
Relevant Lines: 24196

💛 - Coveralls

src/parser/mod.rs Outdated Show resolved Hide resolved
src/ast/mod.rs Outdated
@@ -733,6 +733,10 @@ pub enum Expr {
///
/// See <https://docs.snowflake.com/en/sql-reference/constructs/where#joins-in-the-where-clause>.
OuterJoin(Box<Expr>),
ColumnWithDataType {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we include a description for this new variant (ideally including a link to the docs)?

Copy link
Author

Choose a reason for hiding this comment

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

Sure!

src/ast/mod.rs Outdated
Comment on lines 736 to 805
ColumnWithDataType {
columns: Box<Expr>,
data_type: DataType,
},
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering if naming wise, 'ColumnWithDataType' sounds a bit too generic since it applies to a lot of unrelated scenarios. From the docs, it sounds incorrect as well to have the columns: Box<Expr>?

  • The actual column in WHERE a = {b:INT} is a, while b would be more of a function parameter
  • b given its a function parameter likely needs to be an Ident instead of an Expr

thinking roughly something along this line could be more descriptive

ParameterizedViewArg{
    name: Ident,
    data_type: DataType,
}

Copy link
Author

Choose a reason for hiding this comment

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

Sure, I'll change it

Comment on lines 869 to 962
if dialect_of!(self is ClickHouseDialect) && self.peek_token().token == Token::LBrace {
return self.parse_column_with_data_type();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Currently the parse logic for this feature is spread across this and the parse_infix function where one triggers the other indirectly, slightly harder to follow as a result - one suggestion to simplify this would be:

  • The current function already includes a match onthe token type, so we can introduce a clause
    Token::LBRACE if dialect_of!(self is Clickhouse) => {
        self.prev_token();
        self.parse_column_with_data_type()
    }
  • The current parse_column_with_data_type can parse the components directly - especially given that it does not seem correct for it to parse an inner expression. It becomes
    // consume LBRACE
    let name = self.parse_identifier()?;
    self.expect(Token::Colon)?;
    let data_type = self.parse_data_type()?;
    // consume RBRACE

Copy link
Author

@Lordworms Lordworms Mar 17, 2024

Choose a reason for hiding this comment

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

makes sense to me.

@Lordworms Lordworms requested a review from iffyio March 18, 2024 02:46
@alamb alamb changed the title support clickhouse parametrised views support clickhouse parameterized views Apr 7, 2024
Copy link
Collaborator

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thank you @Lordworms -- this is a really nice contribution . I think it just needs a little polish and would be ready to go

fyi @flipchart

src/ast/mod.rs Outdated Show resolved Hide resolved
src/parser/mod.rs Show resolved Hide resolved

// ClickHouse support using {column:Datatype} format in its creation of parametrised views
match self.peek_token().token {
Token::LBrace if dialect_of!(self is ClickHouseDialect) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you please also support this syntax in GenericDialect as well as explained in https://github.com/sqlparser-rs/sqlparser-rs?tab=readme-ov-file#new-syntax ?

(also add test for it below)

Copy link
Author

Choose a reason for hiding this comment

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

sure


#[test]
fn parse_create_parametrised_views() {
clickhouse().verified_stmt("CREATE VIEW view AS SELECT * FROM A WHERE Column1 = {column1:datatype1} AND Column2 = {column2:datatype2}");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you also please test:

  1. In generic dialect
  2. A single column definition
  3. Error case (like where Column1 = {column1})
  4. Error case (like where) (no column definition)

Copy link
Author

Choose a reason for hiding this comment

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

Sure, I'll add these tommorrow

alamb
alamb previously approved these changes Apr 9, 2024
Copy link
Collaborator

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thank you @Lordworms

@alamb
Copy link
Collaborator

alamb commented Apr 9, 2024

I took the liberty of fixing the compile error and pushing a commit to fix it

@alamb alamb dismissed their stale review April 9, 2024 19:56

CI is failing

@alamb
Copy link
Collaborator

alamb commented Apr 9, 2024

Hi @Lordworms -- it seems like there is a real test failure on this PR. Can you investigate?

@alamb alamb marked this pull request as draft April 9, 2024 20:07
@alamb
Copy link
Collaborator

alamb commented Apr 9, 2024

Marking as draft as the PR checks are failing

@Lordworms
Copy link
Author

Hi @Lordworms -- it seems like there is a real test failure on this PR. Can you investigate?

It seems to have some conflict with the DuckDB literal. I'll fix this.

@Lordworms Lordworms marked this pull request as ready for review April 9, 2024 23:45
@Lordworms
Copy link
Author

Lordworms commented Apr 9, 2024

@alamb I have resolved it and would you please take a look at it when you are available? Thanks! Sorry for the failure since this PR has lasted for 3 weeks and I forgot to rebase this branch.

Copy link
Collaborator

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thanks @Lordworms . I have a few more comments -- sorry it takes me so long to review these

src/parser/mod.rs Outdated Show resolved Hide resolved
}
}
#[test]
fn parse_create_parametrised_views() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I may be mistaken, but thinking about this PR some more and I am not sure about the change to parse_prefix

Specifically, by changing that I think it now allows {column:data_type} to appear in any expression (not just a parameterized view).

For example, wouldn't these queries now parse SELECT * FROM foo WHERE x = {column:int} or SELECT x={column:int} FROM foo?

Can you add test coverage for those cases?

Copy link
Author

Choose a reason for hiding this comment

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

Sure

Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
@alamb
Copy link
Collaborator

alamb commented May 3, 2024

I am not sure what the current status of this PR is -- it has a bunch of conflicts and I am not quite sure if it is ready for another review. Sorry for the delay. Marking it as a draft until we sort that out so it isn't on my review queue

@alamb alamb marked this pull request as draft May 3, 2024 17:59
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.

ClickHouse parameterized view
4 participants