I want to use mysql, and also use uuid for the primary key. Is this the right tweak?

[east4ming]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched in the documentation/README.
• I already searched in Google "How to do X" and didn't find any information.
• I already read and followed all the tutorial in the docs/README and didn't find an answer.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Original:

class User(UserBase, table=True):
    id: uuid.UUID = Field(
        sa_column=Column(UUIDC, primary_key=True, default=uuid.uuid4),
    )

Modified, modified to work properly:

from sqlalchemy import Uuid, Column

UUIDC = Uuid(as_uuid=False)

# Database model, database table inferred from class name
class User(UserBase, table=True):
    id: uuid.UUID = Field(
        sa_column=Column(UUIDC, primary_key=True, default=uuid.uuid4),
    )

So, my question is: Is this the right tweak?

Description

I want to use mysql, and also use uuid for the primary key. I have adapted the engine to mysql+pymysql. and started it successfully, but after starting it, accessing the front-end gives me the following error.

backend-1      |   File "/app/.venv/lib/python3.10/site-packages/sqlalchemy/sql/sqltypes.py", line 3625, in process
backend-1      |     value = value.hex
backend-1      | sqlalchemy.exc.StatementError: (builtins.AttributeError) 'str' object has no attribute 'hex'
backend-1      | [SQL: SELECT user.email AS user_email, user.is_active AS user_is_active, user.is_superuser AS user_is_superuser, user.full_name AS user_full_name, user.id AS user_id, user.hashed_password AS user_hashed_password 
backend-1      | FROM user 
backend-1      | WHERE user.id = %(pk_1)s]
backend-1      | [parameters: [{'pk_1': 'f80a09a5-c1cc-4054-af2f-b02389bc85e7'}]]

Operating System

Linux

Operating System Details

Ubuntu 24.04

Python Version

3.10

Additional Context

No response

[elau1004]

You may have a use case for it but is your application globally distributed where a centralized generation of a unique ID for the primary key will be a bottleneck?
If your answer is NO, I suggests not to use UUID. An IDENTITY is much easier to work with. On a straight sprint, comparing 4 bytes of INT32 is going to be 4X faster than comparing 16 bytes of UUID.