1

I started with Symfony 4 and used the Security Components from the "Get Started" tutorial. Everythings went fine. I don't like Integer as ID, so switched to UUID as the ID if the Entity.

Entity schema:

/**
     * @ORM\Id()
     * @ORM\Column(type="guid")
     * @ORM\GeneratedValue(strategy="UUID")
*/
private $id;

[...]

I did the updates till Symfony 5.2 and all components still work. My fault, I didn't saw the deprecated information about the changed UUID processes in a minor update... After updating thru composer to 5.2 nothing works. I get some 503 errors with the hints, that the old way of creating a UUID is not longer working.

So I changed the old, deprecated components... I change the PasswordEncoder to PasswordHasher... I change the old guid type style in the entities to

+ use Symfony\Component\Uid\Uuid;
   /**
     * @ORM\Id()
   - * @ORM\Column(type="guid")
   - * @ORM\GeneratedValue(strategy="UUID")
   + * @ORM\Column(type="uuid", unique=true)
   */
    private $id;

[...]

  + public function __construct()
  +  {
  +      $this->id = Uuid::v4();
  +  }

  - public function getId(): string
  + public function getId(): Uuid
  +  {
  +     return $this->id;
  +  }

I tested the new process on a new, clean project. I'm able to log in, create a user etc. The relations of to entities works fine etc.

BUT i can't migrate my old data to the new binary(16) field, without ForeignyKey errors, or data failures (plain cropped UUID String in a BLOB field).

Long story, short: I searched three days for a migration path for the old GUID fields char(36) to the new binary(16) UUID fields, without double all tables or scripting a CSV ex-/import. Find nothing and my head is too empty for new searchqueries ;) Is there a migrationpath for old projects to the new UUID component on existing data?

ulfilas
  • 21
  • 5
  • Simply put this is a major refactoring of the existing ID data across your entire application. You'll have to modify the doctrine migration file to handle the data conversions and ID value changes for all the affected tables. You can execute `SET FOREIGN_KEY_CHECKS=0` to prevent the insert/update errors and FK cascade operations. If you have triggers on the affect tables, you will also need to disable or delete and recreate them once done. Once all of the columns are converted from the CHAR(36) to BINARY(16) you can execute updates to match the FK associated ID columns. – Will B. Oct 29 '21 at 18:10
  • Done/tried this. In effect, the old UUID where truncated. The MySQL Version ist 5.7.34, so I don't have the UUID_TO_BIN conversions. – ulfilas Oct 30 '21 at 10:19
  • The framework does a ```hex2bin(str_replace('-', '', $uuid)``` conversions of uuid. It seems, that MySQL unhex get the same result. – ulfilas Oct 30 '21 at 10:59

0 Answers0