Thanks Adam, looks like the link you posted covers it all.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-develope
Hi Mark
Thanks for looking into this tricky security issue.
I'm suggesting to use the names frontend_key and backend_key for these two
> concepts.
>
They seem reasonable to me, as long as there's an explanatory comment.
Perhaps it even needs documenting for third party backends.
My second sugge
Hi Lorenzo
Using a different Session model is already supported - see the docs:
https://docs.djangoproject.com/en/3.0/topics/http/sessions/#extending-database-backed-session-engines
. Or is there something beyond that which you wanted?
Thanks,
Adam
P.S. Please don't start your message addressed
Hello fellows!
Has there ever been any discussion about making the Session model from
django.contrib.sessions a swappable model? Sometimes it's required to
enhance the session model in order to track more information. There are
alternatives like django-user-sessions, but replacing the contrib s
The `*_pattern_ops` operators all support ordinary equality comparisons but
not <, <=, >, or >= comparisons. So a regular `WHERE col = 1` would be
able to use a `_like` index. See:
https://www.postgresql.org/docs/current/indexes-opclass.html
But it's still interesting that the query planner al
Yes that one is odd. Looking more closely, django-oauth-toolkit doesn't
make any LIKE queries, and doesn't seem to ever have done so. It seems
rather that PostgreSQL is using the index to fulfill the unique constraint,
as the corresponding '_uniq' index is not being touched:
core=> select indexrel
Makes we wonder under which circumstances an OAuth token would need to be
looked up using LIKE. I would expect the unique b-tree index which covers
exact lookups to be sufficient.
Simon
Le mardi 14 avril 2020 09:01:48 UTC-4, Adam Johnson a écrit :
>
> For some numbers: I just checked on a long-
For some numbers: I just checked on a long-running client project using
PostgreSQL, and it looks like several of the *_like indexes are in use:
core=> select right(indexrelname, 10), idx_tup_read, idx_tup_fetch from
pg_stat_all_indexes where indexrelname like '%_like' order by 1;
right| id
Thanks for your reply Tim,
I also fail to see a "clean" upgrade path. The way I’ve been thinking of,
is to just as you wrote, keep the code for deletion of the index so people
who migrate to the Index-class will get it removed properly. Since it uses
`IF EXISTS` it should be future-proof. We co
Hi all.
The question of using typing, or type hints, or type checking, in (or with)
Django
has come up several times. Whether we would add inline annotations, or use
stub
files, or what?
Most recently, this resulted in a draft DEP[0] to try and formalize the
situation,
followed by a PR[1] ad
10 matches
Mail list logo