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 PM
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 Du
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 classes
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 str
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
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 M
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 wrot
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 from both places.
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 ('U
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/
["'f45fecf0-2cad-4c66-a
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.
>
> I've got a cor
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 informati
12 matches
Mail list logo