[Doctrine migrations] in-depth analysis of database migration components three: Custom data field types

Custom type

According to the official documentation, create a new Tinyinttype class, integrate the type, and rewrite,, and getName getSqlDeclaration convertToPHPValue getBindingType so on.

tinyinttype.php Complete code:

<?phpnamespaceDb\types; UseDoctrine\Dbal\parametertype; UseDoctrine\Dbal\platforms\abstractplatform; UseDoctrine\Dbal\types\type;/*** Extended Dbal component Type ** The Dbal component that the migration component relies on does not support the tinyint type by default* This class is a class that is extended for MySQL to support tinyint types * * @authorTangbo<admin@tbphp. NET> */classTinyinttypeextendstype{ Public functionGetName(){return ' tinyint ';} Public functionGetsqldeclaration(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 functionConverttophpvalue($value,Abstractplatform$platform){return (NULL===$value) ? NULL : (int) $value;} Public functionGetbindingtype(){returnParameterType::INTEGER;}}

The getSqlDeclaration method is used to generate SQL statements, and SQL stitching needs to be handled based on the parameters passed in.

Registering Custom types

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

In this way, you can use tinyint when you write the Migration class code, for example:

 Public functionUp(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 ']);}

Resolving enum type conflicts

The migration component does not support the enum type, nor can it customize the type. If a table already exists in the database with an enum-type field when the component is integrated, the migration command will be executed with an error.

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

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

Conclusion

At this point, we have completed all migration of the migration component and have been able to use it well in the project.

The current integration is a version management approach, which is supported by the migration component by default and is also the Laravel framework integrated migration approach. There is another way to move the diff, and the diff way can control the table structure more accurately.

In the next chapter, we will examine the data migration components such as and integrated diff methods.

In my code base you can view the detailed code of this article, welcome to star.

[Doctrine migrations] in-depth analysis of database migration components three: Custom data field types