Announcement

Collapse
No announcement yet.

Cannot upgrade due to modification of schema.php

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Cannot upgrade due to modification of schema.php

    Hello Espo team,

    we are currently upgrading EspoCRM from version 6.1.10 to 7.0.10. This upgrade fails because with the new version custom database types cannot be registered anymore.

    Before we could register our own types with:

    PHP Code:
    namespace Espo\Custom\Core\Utils\Database\DBAL\FieldTypes;

    use 
    Doctrine\DBAL\Types\StringType;

    class 
    UuidType extends StringType
    {
      const 
    UUID 'uuid';

      public function 
    getName()
      {
         return 
    self::UUID;
      }



    However with the modification of Espo\Core\Utils\Database\Schema\Schema.php in commit https://github.com/espocrm/espocrm/c...f125dcc76d4380 it was made impossible to register own types this way.

    Resp. lines 61 to 65 (diff):

    PHP Code:
    -     protected $fieldTypePaths = [    
    -          
    'application/Espo/Core/Utils/Database/DBAL/FieldTypes',    
    -          
    'custom/Espo/Custom/Core/Utils/Database/DBAL/FieldTypes',    
    -     ];  
    +     private 
    $fieldTypePath 'application/Espo/Core/Utils/Database/DBAL/FieldTypes'

    And in method initFieldTypes() lines 172 to 175 (diff):

    PHP Code:
    protected function initFieldTypes()         {    
    -          foreach (
    $this->fieldTypePaths as $path) {    
    -              
    $typeList $this->getFileManager()->getFileList($pathfalse'\.php$');
    +          
    $typeList $this->getFileManager()->getFileList($this->fieldTypePathfalse'\.php$'); 

    Upgrading with php command.php upgrade produces now following error in the log file and upgrade fails:

    ERROR: Failed to rebuild database schema. Details: Unknown column type "uuid" requested. Any Doctrine type that you use has to be registered with \Doctrine\DBAL\Types\Type::addType(). You can get a list of all the known types with \Doctrine\DBAL\Types\Type::getTypesMap(). If this error occurs during database introspection then you might have forgotten to register all database types for a Doctrine Type. Use AbstractPlatform#registerDoctrineTypeMapping() or have your custom types implement Type#getMappedDatabaseTypes(). If the type name is empty you might have a problem with the cache or forgot some mapping information. at /var/www/html/vendor/doctrine/dbal/src/Exception.php:125
    How can we now cleanly register our own types? We need the types "uuid" and "datetime_immutable" which are present in other tables of the database.

    ----

    - PHP-Version is 7.4.30
    - DB-Version is MySQL 5.7.27
    - Current Espo-Version: 6.1.10

  • #2
    Hi,

    Maybe consider adding a class right in the application/Espo/Core/Utils/Database/DBAL/FieldTypes directory. I'll consider adding the ability to define custom field types somehow but not by the check-if-class-exist-in-custom method.

    Comment


    • #3
      Could you please elaborate what your custom UUID type does? Why you need it.

      The existing set of types in Espo coincides with attribute types in our ORM. It was not designed that this set is supposed to be extended.
      Last edited by yuri; 08-18-2022, 03:09 PM.

      Comment


      • #4
        Hi Yuri!

        Thank you for your response! Yes I could get over the upgrade hurdle by hacking the core for once. For the future it will be great if you can somehow restore the former functionality to hook into the rebuild process and add the custom fields without touching the core classes.

        Additional to the EspoCRM we have another Symfony application in that database which is kind of related to the CRM. Several of the Symfony entities use the UUID data type which is registered by a comment in the ID column, e.g.:

        PHP Code:
        CREATE TABLE registry (
             
        id char(36COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '(DC2Type:uuid)',

        ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

        ALTER TABLE registry ADD PRIMARY KEY (id); 

        The uuid is generated by the application and will then look like this: 00386453-8051-4823-a5aa-a305d2f07958.

        I liked the former class check approach as it corresponded with the behaviour of the other code extensibility. But any other way is welcome as well.

        Kind regards,
        Martin


        Comment

        Working...
        X