-
-
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
SchemaTool: Better way to manipulate Column definitions #4676
Comments
Is it the primary goal of your listener? In this case, you can try using |
So I did a bit of code archaeology, it seems I added the datetime code in 2014 to an already existing event listener which translates ENUM fields from legacy databases. I guess I didn't notice I guess I will still need the listener for the ENUM stuff, because DBAL probably can't help me there, right? But also, ENUM is probably something where you actually don't want the normalization to run, so maybe all is well then? |
You'll have to be more specific. What translation does the listener perform? |
nothing fancy, really. I sets the type to string and saves the original type information in the comment field: public function onSchemaColumnDefinition(SchemaColumnDefinitionEventArgs $args)
{
$column = array_change_key_case($args->getTableColumn(), CASE_LOWER);
$type = strtok($column['type'], '()');
if ($type == 'enum') {
$options = [
'length' => 255,
'default' => $column['default'] ?? null,
'notnull' => $column['null'] != 'YES',
'comment' => $column['type']
];
$args->preventDefault();
$args->setColumn(new Column($column['field'], Type::getType(Types::STRING), $options));
}
} |
Thanks, @flack. This looks like a valid, generic enough case where you'd just like to override the default behavior. IMO, it deserves a BC break and an API change since the current API doesn't allow it to do it reasonably. |
Just stumbled upon this in my own project also because of a custom DateTime implementation. |
Feature Request
Summary
I am maintaining a Doctrine based emulation layer for a different ORM API. For various backwards compatibility reasons, among other things I replace DBAL's
DateTimeType
with my own implementation. This gets set in myMappingDriver
, and to allow for schema updates, it also needs to be set in the return value ofSchemaTool::getSchemaFromMetadata
. To my knowledge, the only way to do this is to register a listener foronSchemaColumnDefinition
which instantiates the column with the needed type. It looks more or less like this:If you use such a listener, you will have to call
$args->preventDefault()
, because otherwise your changes will get immediately overwritten:dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php
Lines 811 to 821 in 628e846
This means that
AbstractSchemaManager::_getPortableTableColumnDefinition
never gets called on your custom column, so none of the regular normalization code runs and you will instead have to copy whatever you need for the platforms you support into youronSchemaColumnDefinition
listener.It would be a lot more maintainable if there was a way to use all the work DBAL is doing and then only tweak the resulting
$column
(or maybe you could manipulate_getPortableTableColumnDefinition
's$tableColumn
parameter before it gets called?). One idea that came up in #4671 was to maybe pass$column
as an argument to theonSchemaColumnDefinition
callback, another was to have aColumnProvider
interface that users could implement.The text was updated successfully, but these errors were encountered: