[Doctrine Migrations] database migration components in depth parsing 3: custom data field types

The custom type

According to the official document, create new TinyIntType class, integrate Type, and override getName, getSQLDeclaration, convertToPValue, getBindingType and other methods.

TinyIntType.php

<? php namespace db\types; use Doctrine\DBAL\ParameterType; use Doctrine\DBAL\Platforms\AbstractPlatform; use Doctrine\DBAL\Types\Type; /** * Extend DBAL component types ** Migrated component dependent DBAL components do not support TinyInt type by default ** This class is extended for MySQL to support TinyInt type ** @Author Tangbo <[email protected]> */ class TinyIntType extends Type { public function getName() { return 'tinyint'; } public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform) { $sql = 'TINYINT'; if (is_numeric($fieldDeclaration['length']) && $fieldDeclaration['length'] > 1) { $sql .= '(' . ((int) $fieldDeclaration['length']) . ')'; } else { $sql .= '(3)'; } if (! empty($fieldDeclaration['unsigned'])) { $sql .= ' UNSIGNED'; } if (! empty($fieldDeclaration['autoincrement'])) { $sql .= ' AUTO_INCREMENT'; } return $sql; } public function convertToPHPValue($value, AbstractPlatform $platform) { return (null === $value) ? null : (int) $value; } public function getBindingType() { return ParameterType::INTEGER; }}

The getSQLDeclaration method is used to generate the SQL statement, which needs to process the SQL concatenation according to the parameters passed in.

Register a custom type

Type::addType(TinyIntType::TYPENAME, 'db\types\TinyIntType');
$connection->getDatabasePlatform()->registerDoctrineTypeMapping(TinyIntType::TYPENAME, TinyIntType::TYPENAME);

In this way, you can use TinyInt when writing migration class code, for example:

public function up(Schema $schema): void
{
    $table = $schema->createTable('test1');
    $table->addColumn('id', 'integer')->setUnsigned(true)->setAutoincrement(true);
    $table->addColumn('status', 'tinyint')->setLength(2)->setDefault(1);
    $table->setPrimaryKey(['id']);
}

Resolve enum type conflicts

The enum type is not supported by the migration component and cannot be customized. If there are already tables in the database and fields of type ENUM when the migration component is integrated, an error will be reported when the migration command is executed.

To solve this problem, we need to map enum to string:

$connection->getDatabasePlatform()->registerDoctrineTypeMapping('enum', 'string');

conclusion

At this point, we have completed all of the migration of the component and are ready to use it in our project.

The current integration is version management, which is supported by the migration component by default, and is also the migration mode of Laravel framework integration. There is another diff migration mentioned earlier, which allows you to control the table structure more precisely.

The next chapter takes a closer look at how to integrate a diff style data migration component.

in
My code baseYou can view the detailed code for this article, and welcome STAR.