-
Notifications
You must be signed in to change notification settings - Fork 8
Description
sqlparser supports parsing qualified table names (i.e. "database"."schema"."table"). The returned name from TableFactor::Table{name, ..} from the AST is a ObjectName which is represented as a Vec<String> internally. Since special characters can be apart of the name, using something like . as a delimiter in the qualified name is not good enough and will run into issues in niche cases.
Currently, sqlx-ts assumes the first identifier as the name, which incorrectly parses the following example SQL:
SELECT a, b, 123, myfunc(b) FROM my_database.table_1 WHERE a > b AND b < 100 ORDER BY a DESC, bThis is a modifed example from sqlparser's just with a mock qualified name:
https://github.com/apache/datafusion-sqlparser-rs/blob/d9b53a0cdb369124d9b6ce6237959e66bad859af/examples/parse_select.rs#L24-L27
If you run the sqlparser example with this query, the produced AST groups the database and table identifier together. Printing the TableFactor::Table.name produces the full qualified name.
After the TableFactor::Table is matched, the names seems to be determined by DisplayObjectName which pulls the first identifier within the array of identifiers for the table:
sqlx-ts/src/ts_generator/sql_parser/quoted_strings.rs
Lines 33 to 38 in 5c5d3c1
| let first_part = &self.0 .0[0]; | |
| if let Some(ident) = first_part.as_ident() { | |
| let quote_style = &ident.quote_style; | |
| let name = &ident.value; | |
| let name = trim_table_name(name, quote_style); | |
| write!(f, "{name}") |
There seem to be sporadic occasions that refer to the first identifier when dealing with the table, but ultimately when the lexer reaches this point with the table name, it looks up the wrong table name:
| let table_details = &DB_SCHEMA.lock().await.fetch_table(&vec![table_name], db_conn).await; |