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

Remove default schema qualification #15

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
Jun 20, 2024

Conversation

BenoitRanque
Copy link
Contributor

Supporting non-default schemas was done by qualifying tables with a schema.

This was problematic for two reasons:

  • old metadata needed to be updated
  • the names of the generated hasura types changed due to tables being qualified

Both of these manifested as breaking changes.

This PR changes that behavior. Now tables in the default schema won't be qualified, which means behavior as far as hasura is concerned will be the same as 2.36.2 (last version before breaking change)

This fix involved an overhaul of aliasing, which before used to work by modifying the query. Now, tables and columns are aliased when referenced in the query.

@BenoitRanque BenoitRanque self-assigned this Mar 14, 2024
@BenoitRanque
Copy link
Contributor Author

casting.rs moved from query_builder.rs, probably does not need review
aliasing.rs removed, replaced by use of TableContext throughout query_builder.rs
table_context.rs is new, used throughout query_builder.rs

I created a new TableContext struct, and where previously I would pass around a TableName (a vector of strings, identifying a possibly qualified table), I now pass a TableContext which is built from a TableName

A TableContext is created from a TableName by splicing it into its parts (schema name and table name), validating it (verifying we get the expected vector with one or two string members) and attaching the relevant TableConfiguration, if any.

The table_ident and column_ident methods of TableContext will remove any aliases based on the TableConfiguration, if any.
We expect to use those methods in query_builder anytime we generate an identified for a table/column.

We should not use those methods when referencing an already aliased table/column from a subquery.

Eg: given the below sql, we'd expect baz and t4 to be the only places where a column and table alias may be applied.

SELECT t1.foo as bar
FROM (
  SELECT t3.baz as foo
  FROM t4 AS t3
) AS t2

The subtle way we may have bugs here is if we either didn't alias a column identifier that needs aliasing, or did alias a column identifier that does not need aliasing. If such a bug exists (I tried my best to get this right) it would manifest as failing SQL statements for specific queries when aliasing is configured.

Documenting all the above here in case we do run into this problem in the future and need to revisit this.

@BenoitRanque BenoitRanque merged commit 70e0df7 into main Jun 20, 2024
@BenoitRanque BenoitRanque deleted the remove-default-schema-qualification branch June 20, 2024 15:09
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