3 ms·

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

• bakugo 2y ago
  > 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.
• donatj 2y ago
  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
  • la64710 2y ago
    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.
• crockeo 2y ago
  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.
• crooked-v 2y ago
  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.
• deleted 2y ago
  [deleted]
• TheCleric 2y ago
  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”
• sjansen 2y ago
  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.
  • jacob019 2y ago
    default=lambda: str(uuid.uuid4())
    • pvillano 2y ago
      ChatGPT, rewrite this as a named function Sure, ``` UUID4 = uuid.uuid4() def default_id(): return UUID4 ```
      • deleted 2y ago
        [deleted]
• Neywiny 2y ago
  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.
• pfisherman 2y ago
  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.