Re: Support for UNLOGGED tables in PostgreSQL

2015-07-19 Thread Curtis Maloney
I second what Aymeric say rather than take on the burden of
maintaining correct warnings, let's point at the people whose
responsibility it really is :)

--
Curtis

On 20 July 2015 at 06:44, Aymeric Augustin
 wrote:
> I agree with pointing to the relevant section of the PostgreSQL 
> documentation. It will always be more complete, accurate and up-to-date that 
> what we could write.
>
> --
> Aymeric.
>
>
>
>> On 19 juil. 2015, at 19:43, Christophe Pettus  wrote:
>>
>> 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  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 
 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.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to 

Re: Support for UNLOGGED tables in PostgreSQL

2015-07-19 Thread Aymeric Augustin
I agree with pointing to the relevant section of the PostgreSQL documentation. 
It will always be more complete, accurate and up-to-date that what we could 
write.

-- 
Aymeric.



> On 19 juil. 2015, at 19:43, Christophe Pettus  wrote:
> 
> 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  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 
>>> 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.

-- 
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 

Re: Support for UNLOGGED tables in PostgreSQL

2015-07-19 Thread Christophe Pettus
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  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 
>>  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.


Re: Support for UNLOGGED tables in PostgreSQL

2015-07-19 Thread Luke Plant
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  
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.


Re: Why Django is making migrations for external apps?

2015-07-19 Thread Anssi Kääriäinen
To me it seems the choice of doing migrations for app/model should be done
by the author of the app.

How about model/app level setting migrations_mode, where the choices are
auto, manual and never. Auto is the defaul and behaves like current Django.
Manual means that you'll have to mention the app explicitly for
makemigrations. This would be a good default for Django's apps and for 3rd
party apps. Finally never disables migrations for the app entirely, both
creation and applying of migrations.

 - Anssi

On Sunday, July 19, 2015, Shai Berger  wrote:

> On Friday 17 July 2015 19:48:30 Carl Meyer wrote:
> > On 07/17/2015 10:38 AM, Marcin Nowak wrote:
> > > Sounds enough good. One important thing for me is that I have many of
> > > external apps and few in project managed by me. Reconfiguring most of
> > > apps just to tell Django "leave them alone" sounds like an overhead.
> > > That's why I would like to tell Django "here are my apps, manage them
> > > please".
> >
> > I think we need to clarify what this proposed feature does, exactly.
> > James' AppConfig proposal (with the parallel to unmanaged models) sounds
> > to me like a "migrations should ignore this app entirely" flag (which
> > would impact both `makemigrations` and `migrate`). Such a flag wouldn't
> > be useful for any reusable app that has models (and thus migrations).
> > I'm not opposed to this, though (much like unmanaged models themselves)
> > I don't think it'll be frequently used. It's basically a way to opt out
> > of migrations entirely.
> >
>
> Agreed.
>
> > It seems like what Marcin wants is more of a "don't ever create new
> > migrations for this app, but go ahead and use its existing ones
> > normally" flag (thus something that affects only `makemigrations`, not
> > `migrate`).
>
> That's what I'd want too.
>
> > Personally I don't really see much use case for this feature
> > except as a workaround for reusable apps that generate spurious new
> > migrations based on settings changes
>
> I've also seen it with apps that use "EmailField" without specifying
> explicit
> length (which I'd expect to be the common way to use it...)
>
> > (e.g. the dynamic-choices case).
> > Normally an app shouldn't ever generate a new migration from
> > `makemigrations` unless you've modified its models code. So I'd be more
> > in favor of addressing the actual problems causing spurious new
> migrations.
> >
>
> That's "the best getting in the way of the good". Solving the problem at
> the
> source is best, and making reusable apps more robust in this sense is a
> great
> cause, but it shouldn't stop us from putting workarounds in the hands of
> users.
>
> > Also, FWIW, the latter is already fairly easy to implement yourself by
> > overriding `makemigrations` in your project and giving it a default list
> > of app names if none are provided.
> >
>
> I don't think that's a good answer for users (and it can't even be
> implemented
> as a reusable app without adding a setting).
>
> Shai.
>

-- 
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/CALMtK1HfFTEEmm7m1UDVhcTX2xiGfjRpN105yqq0h6FY2zHXpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Why Django is making migrations for external apps?

2015-07-19 Thread Shai Berger
On Friday 17 July 2015 19:48:30 Carl Meyer wrote:
> On 07/17/2015 10:38 AM, Marcin Nowak wrote:
> > Sounds enough good. One important thing for me is that I have many of
> > external apps and few in project managed by me. Reconfiguring most of
> > apps just to tell Django "leave them alone" sounds like an overhead.
> > That's why I would like to tell Django "here are my apps, manage them
> > please".
> 
> I think we need to clarify what this proposed feature does, exactly.
> James' AppConfig proposal (with the parallel to unmanaged models) sounds
> to me like a "migrations should ignore this app entirely" flag (which
> would impact both `makemigrations` and `migrate`). Such a flag wouldn't
> be useful for any reusable app that has models (and thus migrations).
> I'm not opposed to this, though (much like unmanaged models themselves)
> I don't think it'll be frequently used. It's basically a way to opt out
> of migrations entirely.
> 

Agreed.

> It seems like what Marcin wants is more of a "don't ever create new
> migrations for this app, but go ahead and use its existing ones
> normally" flag (thus something that affects only `makemigrations`, not
> `migrate`).

That's what I'd want too.

> Personally I don't really see much use case for this feature
> except as a workaround for reusable apps that generate spurious new
> migrations based on settings changes

I've also seen it with apps that use "EmailField" without specifying explicit 
length (which I'd expect to be the common way to use it...)

> (e.g. the dynamic-choices case).
> Normally an app shouldn't ever generate a new migration from
> `makemigrations` unless you've modified its models code. So I'd be more
> in favor of addressing the actual problems causing spurious new migrations.
> 

That's "the best getting in the way of the good". Solving the problem at the 
source is best, and making reusable apps more robust in this sense is a great 
cause, but it shouldn't stop us from putting workarounds in the hands of 
users.

> Also, FWIW, the latter is already fairly easy to implement yourself by
> overriding `makemigrations` in your project and giving it a default list
> of app names if none are provided.
> 

I don't think that's a good answer for users (and it can't even be implemented 
as a reusable app without adding a setting).

Shai.