Re: Changing the primary key of Django models

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

Re: Changing the primary key of Django models

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

Re: remove support for unsalted password hashers?

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,

Changing the primary key of Django models

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

Re: remove support for unsalted password hashers?

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: > >

Re: remove support for unsalted password hashers?

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

Re: django template modules compiled with cython

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

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

Re: remove support for unsalted password hashers?

> 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? >

Re: remove support for unsalted password hashers?

> > 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

Re: [Question] MySQL Microseconds stripping

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