Re: LiveServerTestCase vs StaticLiveServerCase

[Harry Percival]

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.

More advanced users who are managing their static assets totally
differently -- on a CDN, say -- can then use the more restrictive
LiveServerTestCase if they want to.  Although the default test case would
still work just fine for them.

Maybe there's a parallel with TestCase and TransactionTestCase? The first
will work in 90% of cases, the latter you can use if you have some more
specialised requirements...





On 29 March 2014 23:55, Carl Meyer  wrote:

> On 03/29/2014 02:36 PM, Shai Berger wrote:
> > On Saturday 29 March 2014 19:11:17 Harry Percival wrote:
> >>
> >> What I *am* saying is that, in my opinion, there's not much point in
> >> LiveServerTestCase if it doesn't do static files.  So, to keep things
> >> simple, it would be simpler to remove it, and just have on LiveServer
> test
> >> class, that lives in .contrib if it has to...
> >>
> >> But maybe others would disagree?
> >>
> >> To explain a bit more -- what is LiveServerTestCase for?  It's to let
> you
> >> run tests with (eg) selenium, against a "real" web server.  And one of
> the
> >> most obvious reasons to do that is to test client-side stuff like
> >> javascript, ie stuff that depends on static files.  And so that means
> that
> >> you have to either run collectstatic before every test run, or switch to
> >> StaticLiveServerCase.
> >>
> >
> > FWIW, I've been using LiveServerTestCase to test an app that, in some
> > circumstances, needs to send requests to other servers; in essence,
> mocking
> > those other servers. It's been very useful for this, and it does not
> require
> > any statics.
> >
> > Granted, that is a fringe case, and the main use-case remains tests
> involving
> > real browsers. Just pointing out that a LiveServerTestCase with no
> support for
> > statics does have real uses.
>
> Contrib.staticfiles is an optional way of handling static assets in
> Django. It probably is the most commonly-used way, but it is not
> required. It is possible to write a fully-functional Django project that
> uses static assets without using contrib.staticfiles to manage them.
>
> IMO this is good enough reason for both LiveServerTestCase and
> StaticLiveServerTestCase to exist.
>
> Carl
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/SYktTEJXWc8/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/53375D83.8060209%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACFvh9_cPuJ5ffd4CoO4SaLKSbqBi06YgnTohR1yBnrd6NMNkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

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 does this fit with
the fact that `null=False` is the default for all Field types?


On 29 March 2014 23:37, Ryan Hiebert  wrote:

> I thought TextField did have a default, the empty string?
>>
>> Like every other field, the "default default" is None (NULL).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/PWPj3etj3-U/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABpHFHQK9UdEK6x4Mb3eDqXd5f%3D9egzJp5A21UZYXAQJw8HRDw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACFvh99HKa6SM431dDsfLUmsvfJt9BszEgRJ7uZxexO-Tpo39Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Shai Berger]

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 right?
> 
> So, I realise we're getting sidetracked here, but,  how does this fit with
> the fact that `null=False` is the default for all Field types?
> 

Simply: The "default default" is that fields are required.

But this is very deep in django-users territory.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201403301513.23581.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving aggregate support (#14030)

[Josh Smeaton]

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. I plan to have the documentation in a ready 
for review state next weekend.

I'd really appreciate some reviewing of the code and the approach though, 
ideally before master diverges too much and makes merging too difficult.

Cheers,

Josh

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6d07962d-7fc4-4ca2-9fa6-564a4e759346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trac #22343 -- select-for-update in autocommit mode

[Shai Berger]

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 -- for some projects, app they have used
> > happily before will suddenly break. These projects should probably be
> > thankful -- they were running with a subtle bug that is now exposed --
> > but still.
> > 
> > Unless there are convincing objections to this, I'd even like to backport
> > this change, at least to 1.6, because of the potential data-corruption
> > bugs.
> 
> Yes please.
> 

While fixing this, I ran into this line in the current docs:
"""
Using select_for_update on backends which do not support SELECT ... FOR UPDATE 
(such as SQLite) will have no effect.
"""

This raises two questions:

1) This is a little inconsistent with the approach suggested above -- on 
SQLite, we allow code that asks for locks to run without them. Should we re-
think one of these decisions? That is, should we let select_for_update run 
with no effect when there is no transaction, or, conversely, reject it entirely 
on SQLite?

My view is that for SQLite, the guarantees of data correctness are so low 
anyway,  that we can allow this to pass, while on other backends the user 
should expect better -- so, just do the change suggested above, in spite of 
the apparent inconsistency.

2) Given the above -- should select_for_update be allowed in autocommit mode 
on SQLite?

The argument here is that the most common (and only recommended) use of SQLite 
with Django is for testing; disallowing select_for_update+autocommit+SQLite 
may help people find problems faster. The counter-argument is that if the call 
is not supposed to have any effect anyway, why bother validating that its 
effect 
isn't nullified by the transaction mode?

Again, I tend towards the "status quo" -- let select_for_update queries be 
executed in autocommit mode on SQLite. People should be testing on databases 
they use for production; if all they use is SQLite, we shouldn't get in their 
way, and good luck to them.

But if anybody disagrees, please speak up,

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201403301948.02831.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Andrew Godwin]

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
you then. If not, open a bug report!

Andrew


On Sun, Mar 30, 2014 at 5:13 AM, Shai Berger  wrote:

> 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 right?
> >
> > So, I realise we're getting sidetracked here, but,  how does this fit
> with
> > the fact that `null=False` is the default for all Field types?
> >
>
> Simply: The "default default" is that fields are required.
>
> But this is very deep in django-users territory.
>
> Shai.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201403301513.23581.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1urwhyZkfF9smfeeSOeS_8ejFdKmKo3X%3D4yfWd8DGU_%3DTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: LiveServerTestCase vs StaticLiveServerCase

[Carl Meyer]

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` before each test run, would feel like a
> good default.
> 
> More advanced users who are managing their static assets totally
> differently -- on a CDN, say -- can then use the more restrictive
> LiveServerTestCase if they want to.  Although the default test case
> would still work just fine for them.
> 
> Maybe there's a parallel with TestCase and TransactionTestCase? The
> first will work in 90% of cases, the latter you can use if you have some
> more specialised requirements... 

What does "default" mean in this case? In what way is one of these more
"default" than the other? Neither one is used by the default project
template.

In terms of code location, it makes sense that the "basic" version lives
in core, and the version that relies on contrib.staticfiles extends the
core version and lives in contrib.staticfiles.

Maybe there's a documentation patch you're thinking of to direct people
more clearly to StaticLiveServerTestCase? Currently it looks like that
only happens in the "changed in Django 1.7" note at the bottom of that
section.

Carl



signature.asc
Description: OpenPGP digital signature

Re: Trac #22343 -- select-for-update in autocommit mode

[Anssi Kääriäinen]

On 03/30/2014 07:48 PM, Shai Berger wrote:

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 -- for some projects, app they have used
happily before will suddenly break. These projects should probably be
thankful -- they were running with a subtle bug that is now exposed --
but still.

Unless there are convincing objections to this, I'd even like to backport
this change, at least to 1.6, because of the potential data-corruption
bugs.

Yes please.


While fixing this, I ran into this line in the current docs:
"""
Using select_for_update on backends which do not support SELECT ... FOR UPDATE
(such as SQLite) will have no effect.
"""

This raises two questions:

1) This is a little inconsistent with the approach suggested above -- on
SQLite, we allow code that asks for locks to run without them. Should we re-
think one of these decisions? That is, should we let select_for_update run
with no effect when there is no transaction, or, conversely, reject it entirely
on SQLite?

My view is that for SQLite, the guarantees of data correctness are so low
anyway,  that we can allow this to pass, while on other backends the user
should expect better -- so, just do the change suggested above, in spite of
the apparent inconsistency.
On SQLite we could also ensure we have locked the database. On SQLite 
there can't be multiple writing transactions to the database, and if you 
do select_for_update you are certainly going to write to the db. So the 
right approach seems to be that the database is write locked already 
when we do the select. There is even a dedicated RESERVED lock type for 
this in SQLite. It seems the way to acquire RESERVED lock is to do a 
no-effect UPDATE, that is "UPDATE thetable set pk = 0 where 1 = 0" 
should give RESERVED lock to the database according to section 7.0 of 
SQLite's docs [https://www.sqlite.org/lockingv3.html].


 - Anssi

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/533908D1.5000304%40thl.fi.
For more options, visit https://groups.google.com/d/optout.