After far too long, this ticket has been created:
https://code.djangoproject.com/ticket/21961
If there's general consensus that this feature is worth working on, I'll see
about a 1.7-targeted patch for it.
On Sep 28, 2013, at 10:16 AM, Anssi Kääriäinen wrote:
>
>
> On Saturday, Sept
On Saturday, September 28, 2013 4:31:18 AM UTC+3, Xof wrote:
>
>
> On Sep 27, 2013, at 2:56 PM, Anssi Kääriäinen
> >
> wrote:
>
> > 1. What to do if given DB doesn't support cascades in DB (sqlite at
> least, no idea of MySQL)? Initial feeling is that Django should do the
> cascades in Pyt
On Sep 27, 2013, at 2:56 PM, Anssi Kääriäinen wrote:
> 1. What to do if given DB doesn't support cascades in DB (sqlite at least,
> no idea of MySQL)? Initial feeling is that Django should do the cascades in
> Python code in these cases.
It would behave like the standard version, then, yes.
On Friday, September 27, 2013 1:29:29 AM UTC+3, Xof wrote:
>
>
> 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. :)
>
Some things
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
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
12 matches
Mail list logo
