Re: A more useful list of common passwords?

Heya, Curtis! The gzipped file size of the new file is 82K. That's with all 19,999 passwords from Royce's list. I threw together a quick test that compares the default list to the new larger one by checking 10,000 random passwords. Speed difference is negligible, with both varying between 0.8–1.1

Re: A more useful list of common passwords?

By which I mean... hi Brenton! Great to see you being active again :) It's great you've taken the time to do this, and the benefits are very clear [improved security], but what are the costs? Whilst you're at it, what is the new file size? -- Curtis On 03/30/2018 04:26 PM, Curtis Maloney w

Re: A more useful list of common passwords?

What sort of performance impact is this having over the existing list? What's the additional memory load, if any? -- Curtis On 03/30/2018 04:24 PM, Brenton Cleeland wrote: Three years ago Django introduced the CommonPasswordValidator and included a list of 1,000 passwords considered to be "co

A more useful list of common passwords?

Three years ago Django introduced the CommonPasswordValidator and included a list of 1,000 passwords considered to be "common". That list was based on leaked passwords and came from xato.net[1]. I'd like to update the list to a) be from a more reliable / recent source b) be larger and more in l

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

Thank you all for the replies. @Josh Smeaton Essentially yes; specifically I was wondering whether I was failing to consider behaviour that couldn't be modeled via a Q object, since as you mention the current https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relati

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

These queries are actually not equivalent. Consider the following code: >>> r = Related.objects.create(field='related') >>> r.main_set.create(field_one='1', field_two='3') >>> r.main_set.create(field_one='2', field_two='4') >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1')

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It sounds like you understand what the current behaviour is, and you think that it would be better modelled with Q objects, is that the case? I can see where you're coming from, as even the docs explain the difference loosely in terms of AND and OR. Q(entry__headline__contains='Lennon') & Q(ent

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

On 03/30/2018 08:57 AM, Ryan Hiebert wrote: It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ It's also addressed in the

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ On Thu, Mar 29, 2018 at 4:26 PM, Andrew Standley wrote: > I have recently

Django ORM Handling of Reverse Relationships and Multi-Value Relationships

I have recently become acquainted with some ORM behaviour for reverse relationships that "makes no sense", and I'm hoping someone can explain the justification for the current behaviour. This specifically relates to `filter` behaviour referenced in 29271

Re: default values on database level

Yeah seems like `db_default` was the felling, at least last time I scanned through this long-going discussion :D I've had to tweak Django's migration handling a bit to handle our zero-downtime requirements. SQLalchemy has had this for awhile (http://docs.sqlalchemy.org/en/latest/core/defaults

Re: default values on database level

Closing the loop here -- Tim just reopened https://code.djangoproject.com/ticket/470. This feature would also be useful for achieving zero-downtime migrations, as discussed in https://code.djangoproject.com/ticket/29266. Sounds like the design has mostly been agreed -- would a PR be accepted t

Re: adding object level permissions on the core permissions

Hi. To achieve object level permissions you need to write custom authentication backend. Django does provide support for object level permissions but there isn't default implementation because object level permissions have different meaning for different people. See auth docs for more informatio

adding object level permissions on the core permissions

I want to add object level permissions to the Django'd core auth app Permission model. currently permission instances follow this string format '._' ideally i want this object level permissions to follow a similar string format with as few variations from the originals as possible but the mai