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

Bug: Column names equal to keywords are uppercased #95

Closed
RafaelKr opened this issue Mar 28, 2024 · 3 comments · Fixed by #104
Closed

Bug: Column names equal to keywords are uppercased #95

RafaelKr opened this issue Mar 28, 2024 · 3 comments · Fixed by #104
Labels
bug Something isn't working

Comments

@RafaelKr
Copy link

RafaelKr commented Mar 28, 2024

I have the following Column definition in my Symfony project

#[ORM\Entity]
class Queue {
   [...]

    #[ORM\Column(
        insertable: false,
        updatable: false,
        columnDefinition: 'SERIAL',
    )]
    private ?int $autoIncrement = null;

   [...]
}

When generating a migration without --formatted option the column name is auto_increment. But with --formatted the column name will be AUTO_INCREMENT.

The resulting column name should be lowercase.

Edit: The doctrine/sql-formatter version is 1.2.0
Could be related to #93

@greg0ire
Copy link
Member

Cc @rinu

@derrabus derrabus added the bug Something isn't working label Mar 28, 2024
@mvorisek
Copy link
Contributor

I propose to revert #93 as reserved words cannot be assumed to be reserved in context-free grammar especially not knowing what database is used.

Even if someone would partly disagree, the upper casing must not be done by the tokenizer because of what said above.

Here is an example: https://dbfiddle.uk/Hz6SWg8B

lock is "known reserved word" - https://github.com/doctrine/sql-formatter/blob/1.4.0/src/Tokenizer.php#L159 - but:

-select 'x' AS lock;
+select 'x' AS LOCK;

would produce different result as the result will have LOCK column name instead of lock. The tokenizer nor formatter must do such/any change with functional impact.

@derrabus
Copy link
Member

I propose to revert #93 as reserved words cannot be assumed to be reserved in context-free grammar especially not knowing what database is used.

I agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants