This can be achieved by pointing to the relevant section in the PostgreSQL
documentation with a general "Test execution may be sped up by adjusting the
data integrity parameters in PostgreSQL; be sure to read the appropriate
warnings before making any changes" warning.
Putting actual recommended settings in the Django documentation seems, at a
minimum, pointlessly duplicative, and ties the Django documentation to the
current state of the world in PostgreSQL gratuitously.
On Jul 19, 2015, at 10:32 AM, Luke Plant <l.plant...@cantab.net> wrote:
> I agree with Federico on this - as long as we slap a big warning on it —
> "This is dangerous - it could make your database more likely to lose data or
> become corrupted, only use on a development machine where you can restore the
> entire contents of all databases in the cluster easily" — I don't see a
> problem in this being in our docs.
>
> If people refuse to read a clear warning, they shouldn't be doing web
> development. They are just as likely to find similar instructions on the
> internet, but without warnings, and having it in our docs with the warning
> will be helpful.
>
> Having a fast test suite is such an important part of development that it
> shouldn't be held back by attempting to protect the world from people who
> cannot be helped.
>
> Luke
>
> On 16/07/15 16:49, Christophe Pettus wrote:
>> On Jul 16, 2015, at 1:16 AM, Federico Capoano <federico.capo...@gmail.com>
>> wrote:
>>
>>
>>> I also don't like the idea of believing django users are too stupid to
>>> understand that this advice si valid for development only. Generally
>>> python and django users are intelligent enough to properly read the
>>> docs and understand what's written on it.
>>>
>> It's not a matter of being "intelligent" or not. Developers are busy and
>> can simply google things, see a particular line, and drop it in without
>> fully understanding exactly what is going on. (Simply read this group for a
>> while if you don't believe this to be the case!) People already turn off
>> fsync, in production, after having read the PostgreSQL documentation,
>> without actually realizing that they've put their database in danger.
>>
>> Among other things, developers often have local data in their PostgreSQL
>> instance that is valuable, and advising them to do a setting that runs the
>> risk of them losing that data seems like a bad idea.
>>
>> The Django documentation is not the place to go into the ramifications of
>> fsync (or even synchronous_commit, although that's significantly less risky).
>>
>> --
>> -- Christophe Pettus
>>
>> x...@thebuild.com
>>
>>
>>
>
> --
> "I was sad because I had no shoes, until I met a man who had no
> feet. So I said, "Got any shoes you're not using?" (Steven Wright)
>
> Luke Plant ||
> http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/55ABDF21.9060106%40cantab.net.
> For more options, visit https://groups.google.com/d/optout.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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/648BE2F3-E869-4E9D-BCB9-248E425D5A1C%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.
