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