Hi Christophe,
On 09/26/2013 04:28 PM, Christophe Pettus wrote:
> On Sep 26, 2013, at 2:32 PM, Carl Meyer wrote:
>> We already provide the on_delete=DO_NOTHING option for people who
>> want to push cascade handling to the database.
>
> It's better than the previous situation, but the steps requi
On Sep 26, 2013, at 3:28 PM, Christophe Pettus wrote:
> Perhaps a CASCADE_DB and SET_NULL_DB options on on_delete?
And, to be clear, I *am* volunteering to take a go at this code, not just
whine. :)
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are sub
On Sep 26, 2013, at 2:32 PM, Carl Meyer wrote:
> We already provide the on_delete=DO_NOTHING option for people who want
> to push cascade handling to the database.
It's better than the previous situation, but the steps required to make this
work make it a non-starter for any but the most trivia
I think it would make a lot of sense to require an explicit `on_delete` when
a ForeignKey is nullable because of the ambiguity concerns raised on Trac.
However I'm not convinced this should be required for non-nullable ones
since, IMHO, CASCADE is the most sensible default in this case.
Le jeudi
On Friday, September 27, 2013 12:17:26 AM UTC+3, Xof wrote:
> I also think we *really* need to push execution of this functionality into
> the database rather than having the Django core do it, if we're going to be
> making more use of on_delete.
>
Do you mean that cascading deletes should be
On 09/26/2013 03:17 PM, Christophe Pettus wrote:
> It's a breaking change, so that's going to be a significant amount of
> upgrade work for existing applications.
Yes, it would certainly require a deprecation path, so people would have
the course of several Django versions to update their code.
>
On Sep 26, 2013, at 11:16 AM, Carl Meyer wrote:
> I think either of these changes, but particularly the latter, is
> significant enough that it deserves a mention here before a decision is
> made.
It's a breaking change, so that's going to be a significant amount of upgrade
work for existing ap
2013/9/26 seocam
How are we going with the release process? Do we have a new date for the RC?
>
Well -- security issues got in the way :( and I'm still pondering over a
release
blocker: https://code.djangoproject.com/ticket/21134
Hopefully I'll deal with it during the week-end. Then the release
Hi,
How are we going with the release process? Do we have a new date for the RC?
Cheers,
--
Sergio Oliveira
On Wednesday, September 11, 2013 3:42:33 PM UTC-3, Aymeric Augustin wrote:
>
> 2013/9/11 >
>
>> Do you have an update on the schedule for the the Final? I guess it would
>> be any week n
Hi all,
I filed a ticket last week suggesting that we change the default from
on_delete=CASCADE to on_delete=SET_NULL for nullable ForeignKeys.[1]
There's been some lively discussion on the ticket, and Michael Manfre
has suggested that we should instead transition to making on_delete a
required a
On 09/26/2013 09:02 AM, Michael Manfre wrote:
> I don't think there will ever be a true consensus. I predict that the
> option that would leave the least number of people unhappy is a settings
> API that allows for 3rd party settings backends. Having settings in the
> environment is ideal for deplo
On Sep 26, 2013, at 2:17 AM, Rocky Meza wrote:
> This is a problem that we ran into with authtools, what we ended up doing was
> just running the tests 3 times[1]. I don't think this is a realistic
> approach within Django core though. One of the main problems with this is
> that you use ge
I don't think there will ever be a true consensus. I predict that the
option that would leave the least number of people unhappy is a settings
API that allows for 3rd party settings backends. Having settings in the
environment is ideal for deployments, but what each project and admin
consider to be
Honestly, I find the idea of *not* using a settings file to be
inconvenient, and the notion of using environment variables for doing
anything aside from pointing to a settings file to be pretty disgusting.
Here are my thoughts, in no particular order:
- Pretty much everyone out there uses some for
(Memo to self: always think about it for a day before replying.)
Okay, I see. And I certainly agree that a few strategically placed
instances of (for example)
>>> psw = os.environ.get('DBPASSWORD', 'DumbDefault')
would help security in most cases.
I will get back to the drawing board, then, an
No, when 12 factor says in the environment, it means exactly that. *NOT*
checked into version control, and in the environment of the shell.
12-factor is talking *only* about number 1 for differences in your
environments.
Yes windows is not very good at environment variables in general, but I
would
Okay, I read it. I think that it argues for structured settings, not
against them.
What I read was a set of guidelines, rather like the Zen of Python. They
look like good, reasonable rules-of-thumb to me, and I have been around
long enough to recognize such. One of the reasons I adopted Pyth
Hi,
I'm another one of the authtools devs.
On Tuesday, September 24, 2013 6:04:17 PM UTC-6, Luke Sneeringer wrote:
>
> Good evening, Russell, et. al.,
> I had some time this afternoon. :-) Since there are already a couple of
> reference implementations for how to do this with an e-mail app, I d
On 26.09.2013, at 01:45, Russell Keith-Magee wrote:
>
> On Thu, Sep 26, 2013 at 4:21 AM, VernonCole wrote:
> I find myself using up lots of time and keystrokes explaining about the
> benefits and methods of a structured settings module in django.
> For example: Using-a-Structured-Settings-e
19 matches
Mail list logo
