Hacker News Reader

Comment by la64710 | Hacker News Reader

I dont get it , line 56 every time it was invoked would call the uuid4 function to generate a unique id isn’t it? Or was the issue due to the uuid4 function not getting invoked for any reason?

View on HN

Line 56 is executed as the file is loaded. Simplified, the line is essentially:

  id = Column(default=str(uuid.uuid4()))

As written, a UUID is generated once and used to set a class-level attribute. Each Python process would generate a unique value, so it wouldn't be immediately obvious. Most of the time Python's ability to run code as a file is loaded is helpful, but this is one the well known gotchas.

Although I'm not a SQL Alchemy user, I assume the fix is essentially the same as it would be for Django. So the correct code would have been essentially:

  id = Column(default=uuid.uuid4)

Instead of executing `uuid4()` and caching a single UUID value, it would have executed `uuid4()` each time a new object was created.

default=lambda: str(uuid.uuid4())

ChatGPT, rewrite this as a named function

Sure,

```

UUID4 = uuid.uuid4()

def default_id():

    return UUID4

```

The issue is that uuid4() would be called a single each time the app was launched when that code was first loaded. Each record produced by an individual instance of the app would have the same ID.

Interesting that more people weren't asking for more explanation on this. I feel like the article did a poor job but other commenters explained it well. More commonly I see this with `def f(x=list()):...` or similar. Linters will even warn about it. It really shows a lack of Python knowledge, so I'll jump on the bandwagon of rewriting this with such pressure was a bad idea.

Since this looks like table definition code it likely would run once per db migration. So in all likelihood it ran once when they created the database tables which itself essentially ended up with a definition like “default=89abcdef-0000-0000-0000-fedcba987654”

It's invoked once when the class is instanced in Python, then reuses that same value for as long as the class lives in memory.

> line 56 every time it was invoked would call the uuid4 function to generate a unique id isn’t it

Yes, but that line is only evaluated once when the class is declared (aka when the application starts), it's not evaluated for every instance.

I'm not a Pythonista, but I think the deal is that line 56 was only executed once, at class definition, so every time the server spun up, you got a new uuid that could only use once

Ah so it would get invoked one time for the first user that resulted in a task (container ) initialization on the backed ECS cluster and once all 40 of the tasks were running new users will just reuse one of the running containers and already instantiated object in memory.

You should generally be setting attributes in the init method of your class, unless you want it to act like a class attribute - shared by all instances. The exception is some special types of classes such as dataclasses or pydantic objects, which do it automatically but require a post init method if you want to do anything more than set values passed to the constructor.

Tbh, if they were writing something for prod they should have factored out the uuid generation and passed values into a pydantic dataclass w/ validators for all the fields. Just sayin.

Reply on news.ycombinator.com