UUIDs eventually choke as primary key

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

UUIDs eventually choke as primary key

M Mackey
I've run into a strange issue with using a UUID as primary key, and I'm hoping we can either verify this is a bug, or figure out what I've done wrong.

I've got a core model object with a UUID for it's primary key. (Generated external to this system, thus using that for when additional information comes in.) And there are other model objects referencing it. Normally everything runs fine. But after a while, web pages that have been running fine start telling me that the UUID isn't valid (even though it is). (Sorry I don't have a copy of the error at this moment, I'll post here when it happens again.) I know it's not a simple coding error, because I can simply restart Apache and everything is fine again. And these aren't POST responses or anything complex like that. It occurs on a simple listing page.

When I dig into the exceptions, I see something that seems contradictory. It looks like the UUID constructor has been called with an instance of a UUID (it says type UUID doesn't have method 'replace'). But it doesn't seem like that should be possible because the code that calls that constructor first checks the type. (See django/db/models/fields/__init__.py - UUIDField.to_python)
So it's a double head scratcher. Once this problem crops up, I have to restart the web server (but then it's okay for a while). And the errors it gives me don't make much sense.
I don't know what kind of caching problem it could be - I haven't enabled any of the available caching systems. Also doesn't seem to crop up (at least not as often) in the built in dev test server.

Anyone seen this, or have any ideas?

Thanks,
M

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d283cde8-76ff-4218-a504-4a92508ae2a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: UUIDs eventually choke as primary key

Ɐha Hah
Use a storage/caching layer of CUIDs instead? http://usecuid.org/

Aha

On Mon, Feb 12, 2018 at 11:24 AM, M Mackey <[hidden email]> wrote:
I've run into a strange issue with using a UUID as primary key, and I'm hoping we can either verify this is a bug, or figure out what I've done wrong.

I've got a core model object with a UUID for it's primary key. (Generated external to this system, thus using that for when additional information comes in.) And there are other model objects referencing it. Normally everything runs fine. But after a while, web pages that have been running fine start telling me that the UUID isn't valid (even though it is). (Sorry I don't have a copy of the error at this moment, I'll post here when it happens again.) I know it's not a simple coding error, because I can simply restart Apache and everything is fine again. And these aren't POST responses or anything complex like that. It occurs on a simple listing page.

When I dig into the exceptions, I see something that seems contradictory. It looks like the UUID constructor has been called with an instance of a UUID (it says type UUID doesn't have method 'replace'). But it doesn't seem like that should be possible because the code that calls that constructor first checks the type. (See django/db/models/fields/__init__.py - UUIDField.to_python)
So it's a double head scratcher. Once this problem crops up, I have to restart the web server (but then it's okay for a while). And the errors it gives me don't make much sense.
I don't know what kind of caching problem it could be - I haven't enabled any of the available caching systems. Also doesn't seem to crop up (at least not as often) in the built in dev test server.

Anyone seen this, or have any ideas?

Thanks,
M

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d283cde8-76ff-4218-a504-4a92508ae2a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAPugQBMoQcth2AwK_KiqJ2ZGRC0Ns3Jurx6CXpvxf4Kp4id8Vw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.