On 03/30/2014 06:02 AM, Harry Percival wrote:
> In that case, maybe the question is: which should be the default?
>
> Given that, as you say, most people use staticfiles, it feels to me like
> the test case in which static files "just work", without having to
> remember to run `collectstatic`
You're roughly right, yes. String fields are a little odd, though, in that
you can have them blank=True without null=True and then the default should
be an empty string (Django's separation of blank and null irks me still) -
the migrations should correctly detect this and insert blank strings for
On Thursday 27 March 2014 19:59:52 Aymeric Augustin wrote:
> On 27 mars 2014, at 15:20, Shai Berger wrote:
> > So I'm suggesting we change the behavior of select-for-update queries, to
> > error out when executed with no transaction. This is a
> > backwards-incompatible change
Code complete: https://github.com/django/django/pull/2496
- Aggregates have learnt arithmetic and how to interact with F() expressions
- Annotations can now accept non-aggregate expressions
I'm in the process of writing documentation, some of which I've committed
and is available within the PR.
On Sunday 30 March 2014 15:08:17 Harry Percival wrote:
> Ah, so the reason I was confused is because it *looks* like the default is
> the empty string, because that's what you get if you initialise an object,
> by default. But at the database level, the default for the column is NULL.
> Is that
Ah, so the reason I was confused is because it *looks* like the default is
the empty string, because that's what you get if you initialise an object,
by default. But at the database level, the default for the column is NULL.
Is that right?
So, I realise we're getting sidetracked here, but, how
In that case, maybe the question is: which should be the default?
Given that, as you say, most people use staticfiles, it feels to me like
the test case in which static files "just work", without having to remember
to run `collectstatic` before each test run, would feel like a good default.