[make:*] allow the option to use ULID's for entity id's

[jrushlow]

• make:entity
• make:reset-password
• make:user

[seb-jean]

Are there any performance issues when using Ulid/Uuid, particularly in relationships between entities?

[jrushlow]

Howdy @seb-jean - from my personal experience, no. That said, I've never profiled persistence calls using int's vs uuid's at scale. Doctrine stores the uuid as a string in persistence.

Usually in my own projects my entities are like:

class SomeEntity
{
    #[ORM\Column]
    private Uuid $id;
    
    public function __construct() {
        $this->id = Uuid::v7();     // or whatever version I need
    }

    public function getId(): Uuid
    {
        ...
    }
}

Often times I'll have the $id in a trait or abstract entity and then just set the id in the class consuming the trait. This is just a personal preference, but I prefer to keep the business logic of generating values in my app's business logic vs relying on doctrine to do it for me. I also never include a setter method as doctrine uses reflection to set the value of $id when fetching a row from persistence and creating the instance of the entity. And because the __construct() method is never called by doctrine, a new uuid is not generated when fetching an entity from persistence.

Anywho, that's just a bit of background on how I use uuid's instead of int's for me entities...

[seb-jean]

I saw a post from @tgalopin several years ago : https://medium.com/@galopintitouan/auto-increment-is-the-devil-using-uuids-in-symfony-and-doctrine-71763721b9a9

[jrushlow]

Ya, I'm not sure if the performance hits still hold true, I could be completely wrong however. The readability in urls definitely is still true. For articles, blog posts, or any searchable entity from a url - sluggifying the entities $title and setting that as the route parameter is the way to go. For backend links, like in admin pages, just using the id in the route param is not going to cause any performance issues.

I do recall, back in the day - databases did not support native uuid's and they would be converted to a string. I fooled around with persisting them as binary but then as uuid support progressed, i gave up on that.

I think the important thing to remember is, how much traffic is your app getting, what your infrastructure looks like, and do you really need to squeeze out an extra 5? ms or so to even worry about any perfomance hits that using uuid's could be causing. If you're netflix - ya, get that 5ms. But based on my experience, its better to use the uuid's like I showed in the example above rather than worring about id collisions / potential security vectors with int's.

[seb-jean]

Thanks a lot for all these informations @jrushlow

[seb-jean]

And regarding URLs, if I have a Post object that has an Ulid id.

Could my base 58 URL /post/1C8t3s1tkRU2NRg9VjLcaF work?

#[Route('/post/{id}', name: 'app_post_show', methods: ['GET'])]
public function show(Request $request, Post $post): Response
{
}

[seb-jean]

@nicolas-grekas you know that using U*IDs as primary keys is a bad practice.. Is this still the case for you?

symfony/symfony#41544 (comment)