Re: Django default PK type setting

On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote: > A major issue with this would be the many apps out in the wild (and their > tests!) that assume the pk is an integer, and do queries like > .filter(pk=1). FWIW, this is a bad practice which we should recommend against. In databases whic

Re: Django default PK type setting

My suggestion wouldn't be mandatory it would be more like a flag when you are starting a new project. So most people would likely never use it. Well I think at this point its safe to say that this is not going to happen. On Wednesday, August 31, 2016 at 4:51:54 PM UTC-7, Josh Smeaton wrote: > >

Re: Add past/present/future validations for Date and DateTime types

Jani is correct, you'll need to be careful to handle timezones if timezones are activated in SETTINGS. I can see value in a django-validators external package that you could expand upon with newer validators as they come up. But whether or not you want to build and maintain such a project is ob

Re: Django default PK type setting

A major issue with this would be the many apps out in the wild (and their tests!) that assume the pk is an integer, and do queries like .filter(pk=1). I don't like the idea of being able to enforce a different kind of pk type for apps that you haven't written yourself. Is there an actual proble

Re: Sonar for the Django rpoject

I'm posting the the 11 criticals. In my opinion, they are not critical, they are just code smells. I will try to export the report so you can review the major issue

Re: Sonar for the Django rpoject

Any security issues should be reported to secur...@djangoproject.com, otherwise it's fine to share the information here. On Wednesday, August 31, 2016 at 2:25:55 AM UTC-4, Ivan Sevastoyanov wrote: > > All the rules are with a default severity so there might be some major > issues that it's worth

Re: Add past/present/future validations for Date and DateTime types

Hi, As Tim pointed out this can easily live as an external package. Also you have to be really careful with dates and specially datetimes when playing with timezones and daylight saving time. Specially since you mention that invoice dates that may belong to past/present/future. On 30.08.201