-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
AbstractSchemaManager#_getPortableTableColumnList()
cannot process functional indexes defined in MySQL
#5306
Comments
At a high level, this is similar to #4470: the DBAL crashes upon encountering a database object that it doesn't understand, while it has a quite limited understanding of the supported platforms. From the design standpoint, in both of these cases, the DBAL might fall back to using some generic types for such objects (i.e. columns and indices). It should operate lower-level raw definitions that won't likely allow comparison but will retain the original properties of the objects. |
Any updates here? and when it is expected to be fixed? |
@YosraHamza this is open source: it is fixed when YOU fix it :P |
@Ocramius I agree with you. I saw the open discussion and related issues so I thought it might be resolved soon. If not, I will give it a try for sure. |
Really not saying this is the proper solution (open to suggestion, but I am looking at this project the first time, so it is likely just some workaround, I am neither a PHP expert nor into databases). https://github.com/lukasm91/dbal/tree/fix_invalid_columns This is just skipping indices that have an index with unknown columns. I ran into this with a typo3 application with a sqlite backend. |
Just encountered this exact same issue. Here is how to reproduce : Applyed the following migration by running <?php
declare(strict_types=1);
namespace DoctrineMigrations;
use Doctrine\DBAL\Schema\Schema;
use Doctrine\Migrations\AbstractMigration;
/**
* Auto-generated Migration: Please modify to your needs!
*/
final class Version20230120105840 extends AbstractMigration
{
public function getDescription(): string
{
return '';
}
public function up(Schema $schema): void
{
// this up() migration is auto-generated, please modify it to your needs
$this->addSql("ALTER TABLE company ADD INDEX idx_siret (( cast(regexp_replace(cast(`corporate_identifier` as char charset utf8mb4),_utf8mb4'[^0-9]+',_utf8mb4'') as unsigned) ))");
}
public function down(Schema $schema): void
{
// this down() migration is auto-generated, please modify it to your needs
$this->addSql('DROP INDEX idx_siret ON company');
}
} Then I ran And this error happened : This error occured because the _addColumn function take a string parameter but mysql functionnal indexes has no column at all, so null is passed to this function and dbal crash. |
Bug Report
Summary
When using functional MySQL indexes, the
AbstractSchemaManager
crashes when instantiating a newIndex
for which the columns could not be identified.How to reproduce
Given following DDL:
Running schema introspection tools lea
The trace is a bit noisy because of this happening in a symfony application, but the last frames are clear.
This happens here:
dbal/src/Schema/AbstractSchemaManager.php
Lines 1066 to 1073 in 35eae23
At this location,
$data['columns'][0]
will benull
for the index defined aboveCurrent behaviour
See above crash - a hard crash is probably to be avoided.
Expected behaviour
Perhaps letting it silently ignore the index? 🤔
In my application, I will likely come up with a workaround that skips this specific index through an event subscriber attached to
\Doctrine\DBAL\Events::onSchemaIndexDefinition
, but it is only a local workaround.The text was updated successfully, but these errors were encountered: