itself? Personally I do not see much gain,
>>> if you have to install a dependency, you could as well just install bcrypt
>>> or argon2 and ditch pbkdf2. For those people where it really makes a
>>> difference, a custom backend as you already have should be just fine.
&
Greetings,
11 months ago, I opened a ticket (#25395) on the bug tracker about
potentially adding a dependency on python-fastpbkdf2, a library I wrote and
maintain that provides a faster implementation of PBKDF2 than the stdlib
while maintaining API compatibility. Tim rightly pointed out that he
I notice that proxy models (classes inheriting other models, and whose
Meta class contains "proxy = True") cannot have new ManyToManyFields.
I'm trying to add an additional ManyToManyField to auth.models.Group
and would like to manage this relationship through the django admin.
It seems that since
lse I can do to help get these committed.
Travis
Propeller.com
Malcolm Tredinnick wrote:
> On Tue, 2009-03-10 at 10:30 -0400, Travis Terry wrote:
> [...]
>
>> So, my proposed fix is to add a flag in WSGIHandler and then test for
>> that flag in __call__().
>>
I have found an incomplete-initialization bug the WSGIHandler when
running under Apache mpm_worker with mod_wsgi.
On the first request the WSGIHandler.__call__(...), we set up the
middleware. There is a lock wrapping the load of the middleware, but
the logic still allows incomplete initializa
Ivan Sagalaev wrote:
>
> Actually there is a common solution to this problem that doesn't create
> duplicates and doesn't fail on second transaction. And as James
> correctly has noted it works on database level. The solution is a form
> of SELECT called SELECT FOR UPDATE. When one transaction
ent a very non-DRY piece of identical code to handle the
situation.
Travis
Leo Soto M. wrote:
> On Dec 4, 2007 3:08 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
>
>> I've run into a problem with get_or_create() with respect to concurrent
>> access of the DB, and
James Bennett wrote:
> Ultimately, the database is the only location from which you can solve
> this problem, because only the database can reliably know when these
> situations are occurring. Solutions implemented outside the DB are
> essentially doomed from the start.
>
> Similarly, an applicat
I've run into a problem with get_or_create() with respect to concurrent
access of the DB, and I have looked at the list archives for advice. I
found some discussions a while back regarding other's problems but no
acceptable solution was ever implemented. I have another proposed
solution that
ure that's a bug. I think it should instead read:
- Terry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@google
10 matches
Mail list logo
