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

add fix for mariadb virtual column creation #2158

Open
wants to merge 2 commits into
base: 0.x
Choose a base branch
from

Conversation

oskarkregar
Copy link

@oskarkregar oskarkregar commented Dec 20, 2022

When using virtual column definition with Literal class, migration fails with SQL syntax error on MariaDB as NOT NULL or NULL are not allowed at the end of column definition. Below is the link to an issue.

Fixes #2157

@ndm2
Copy link
Contributor

ndm2 commented Dec 20, 2022

I'm not sure if it's overly reasonable to completely break the null option for all literal type usages with MariaDB, just because of this one quirks.

Maybe the check should rather look for SQL that is incompatible with [NOT] NULL, or maybe it should be possible to explicitly suppress generating [NOT] NULL?

In any case, this should have tests. Since existing tests didn't break, there seems to already be missing coverage.

@MasterOdin
Copy link
Member

We don't currently test against mariadb, so we'd need to wire that up before we could have a good test for this. MySQL does happily allow null and not null for virtual columns so I wouldn't expect our existing tests to be able to cover this.

@oskarkregar
Copy link
Author

It could then be fixed with option to explicitly suppress null and not null as @ndm2 suggested. It is not needed on most MySQL and MariaDB column creation (except on TIMESTAMP type).

@kyojin007
Copy link

Is there an argument to say that adding options to a Literal column type is unnecessary? By definition we are manually specifying the column and allowing options just adds complexity.

Then we might do;

        if (!$column->getType() instanceof Literal) {
            $def .= $column->getEncoding() ? ' CHARACTER SET ' . $column->getEncoding() : '';
            $def .= $column->getCollation() ? ' COLLATE ' . $column->getCollation() : '';
            $def .= !$column->isSigned() && isset($this->signedColumnTypes[$column->getType()]) ? ' unsigned' : '';
            $def .= $column->isNull() ? ' NULL' : ' NOT NULL';
        }

@dereuromark
Copy link
Member

@ndm2 So you think we shouldn't merge this?

@ndm2
Copy link
Contributor

ndm2 commented Sep 7, 2023

@dereuromark Not in this state, no. IMHO there should either be an option to exclude [not] null generation, or there should be a clear way to define the whole column creation SQL via a Literal object. I would also second @MasterOdin that this should have an actual test on MariaDB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Using Literal for creating virtual columns throws error on MariaDB
5 participants