Hi Adam,
I'm sorry it didnt'work out after all, let me tell you that Python itself
is quite slow and the template engine has some good overhead as well making
this slowlyness even worse, greatly noticed on big or nested loops. Also,
10% increase seems quite low to be important.
I think that if
By the way, the django-developers mailing list is about the development of
Django itself. Please keep usage questions limited to django-users. Thanks!
On Friday, February 5, 2016 at 6:10:04 PM UTC-5, Dheerendra Rathor wrote:
>
> Yes you can keep custom primary key. Pass `primary_key=True` in your
Yes you can keep custom primary key. Pass `primary_key=True` in your model
and Django won't create a primary key for that model.
Here are relevant docs:
https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.Field.primary_key
On Fri, 5 Feb 2016 at 20:52 Uri Even-Chen wrote:
>
I would guess most users aren't customizing the default list of hashers, so
I'd rather remove weak hashers from the PASSWORD_HASHERS setting and let
anyone who needs to use a weak hasher define their own setting (at which
point a warning probably isn't needed). Does that seem okay?
On Friday, F
To django-developers@googlegroups.com,
I'm a Django user and I'm working on converting Speedy Net from PHP to
Django. I would like to know if it's possible in Django to change the
primary key of Django models, such as User? I don't like the auto-increment
default primary key, it doesn't make sense
Adding a check for weak password hashers could be a good compromise to drive
attention to the issue but make it reasonably easy to ignore it if you need MD5
for compatibility with other systems.
--
Aymeric.
> On 5 févr. 2016, at 21:11, Sergei Maertens wrote:
>
> This is my main concern as we
This is my main concern as well. I often migrate old Joomla or other PHP
things that use md5, and it's really convenient that Django upgrades the
passwords for free for me.
Although I guess I could just write the hasher as part of the project and
add it to the setting, but then that's an additi
Hi guys,
I work with Alex here at YPlan. We deployed a tidied updated version of
Alex's code as django-speedboost, since it looked promising in local
profiling. You can see the code here:
https://github.com/YPlan/django-speedboost . It uses a Cythonized version
of Django 1.8.8's template engin
I was thinking of a situation where you have md5 hashes in the database and
want to run both Django and the legacy system at the same time. In that
case, changing the password format in the database might not be an option
if the legacy system needs to read plain hashes instead of Django's format
I'm not sure if we can keep support for unsalted hashes while removing the
special logic in identify_hasher() for those hashers since they don't
confirm to Django's normal hash format?
https://github.com/django/django/pull/6082/files#diff-2f01db46550174ad3e55be7070b98ec9
I guess a use case where
> On Feb 5, 2016, at 10:04 AM, Tim Graham wrote:
>
> I'm not sure if we can keep support for unsalted hashes while removing the
> special logic in identify_hasher() for those hashers since they don't confirm
> to Django's normal hash format?
> https://github.com/django/django/pull/6082/files#d
>
> On Feb 5, 2016, at 7:05 AM, Rafał Pitoń wrote:
>
> Will I still be able to implement unsalted hasher if I so desire?
>
> Don't get me wrong, I understand thats pretty crappy way to store password,
> but there are times when you inherit large set of data from site that you are
> moving fro
Hi,
I've just finished converting all the datetime columns to datetime(6) in
our database after an upgrade to MySQL 5.6. We don't use Django migrations,
many of these were done manually with *pt-online-schema-change*. Just
catching up on this thread, throwing some ideas in.
Why not strip the m
Will I still be able to implement unsalted hasher if I so desire?
Don't get me wrong, I understand thats pretty crappy way to store password,
but there are times when you inherit large set of data from site that you
are moving from some old PHP contraption that happens to be around since
2006,
Ticket closed: https://code.djangoproject.com/ticket/13875
I guess there might other 5-6 year old tickets lying around.. this one in
particular did not have "patch needs improvement" or "easy picking", these
two flags would help wanna be contributors to find this type of tickets,
especially dur
15 matches
Mail list logo
