Re: UUIDs eventually choke as primary key

Hi, I've only been using Django for a few weeks really, so I'm not sure how much I can help, but this is concerning for me, and I'd like to help resolve it. Are you able to just include your full models.py file here? I'll run it on my computer and try to debug too. On Thu, Mar 15, 2018 at 5:20

Re: UUIDs eventually choke as primary key

Hi, I think the problem comes from mod_wsgi. I had the same problem when virtualhost listen on multiple ports. Please look at this GH issue https://github.com/GrahamDumpleton/mod_wsgi/issues/206 and try this by https://github.com/GrahamDumpleton/mod_wsgi/issues/206#issuecomment-305019825 by

Re: UUIDs eventually choke as primary key

Well, I don't seem to be able to get around this. I'm going to have to switch away from using a UUID as a primary key, which fortunately doesn't seem like too much work. On Thursday, March 1, 2018 at 8:53:13 AM UTC-8, M Mackey wrote: > > I added some debug support, and there are only two

Re: UUIDs eventually choke as primary key

I added some debug support, and there are only two classes called UUID when this fails: uuid UUID: psycopg2.extensions UUID: The psycopg extension is a converter, and it seems highly unlikely that it was put into place as the value, and I doubt it would report it's __str__ as the UUID

Re: UUIDs eventually choke as primary key

Not to belabor the point, but this is the part that I find weird. This is down in the "During handling of the above exception ('UUID' object has no attribute 'replace'), another exception occurred" section. /usr/local/venvs/attrack/lib/python3.6/site-packages/django/db/models/fields/__init__.py

Re: UUIDs eventually choke as primary key

Adding details I seem to have left out. The id is defined like this: id = models.UUIDField(primary_key=True, default=uuid.uuid1, editable=False) and I'm running on PostgreSQL. I'm pretty sure I never create a row without already having the key. On Monday, February 12, 2018 at 1:00:53 PM UTC-8, M

Re: UUIDs eventually choke as primary key

My notes don't say I did that, and I tried a new env and sys.path still shows /usr/local/lib/python3.6. Maybe that's just a red herring. But I don't have any other good explanation for the UUID getting passed to the UUID __init__. On Friday, February 23, 2018 at 9:12:33 AM UTC-8, Tom Evans

Re: UUIDs eventually choke as primary key

On Fri, Feb 23, 2018 at 4:20 PM, M Mackey wrote: > I have noticed in the python > path that there are two paths to .../lib/python3.6. One from my virtualenv, > and one at /usr/local/. Not sure where to clear that up, since I don't > believe I've got my apache env set up to pull

Re: UUIDs eventually choke as primary key

The thing that gets me is this part: .../django/db/models/fields/__init__.py in to_python > return uuid.UUID(value) ... > /usr/local/lib/python3.6/uuid.py in __init__ > hex = hex.replace('urn:', '').replace('uuid:', '') ... > > During handling of the above exception

Re: UUIDs eventually choke as primary key

Got it to happen inside the admin interface. It looks like, at least in this case, it's some kind of cache. I don't see the cache stuff on the user's listing page. I'll see if I can put a condensed version of the error here: ValidationError at /admin//log/1418765/change/

Re: UUIDs eventually choke as primary key

Use a storage/caching layer of CUIDs instead? http://usecuid.org/ Aha On Mon, Feb 12, 2018 at 11:24 AM, M Mackey 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. >