On Dec 12, 4:46 pm, Karen Tracey wrote:>
>
> This SELECT:
>
> > {'sql': u'SELECT "vortaro_car"."id", "vortaro_car"."name",
> > "vortaro_car"."owner_id" FROM "vortaro_car" WHERE
> > "vortaro_car"."owner_id" IN (1)',
> > 'time': '0.001'},
> > {'sql': u'DELETE FROM
Following up on #17338 ([nonrel] supports_deleting_related_objects
database feature flag):
carljm said that:
> [Django] is (sort of) _emulating_ SQL cascading deletes, but it does so in a
> way that doesn't assume anything at all from the backend.
I'm not sure this is correct. If I define the
ngo/django/blob/master/django/core/urlresolvers.py#L364
this seems to be only obvious limitation)?
On Oct 12, 4:13 pm, Wilfred Hughes <wilf...@potatolondon.com> wrote:
> > > >>> reverse('i_dont_exist')
> > > NoReverseMatch: Reverse for 'i_dont_exist' with
> > >>> reverse('i_dont_exist')
> > NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
> > keyword arguments '{}' not found.
>
> > In this case, it would be nicer to have something like:
>
> > NoURLPattern: No patterns specified for 'i_dont_exist'.
>
> Just on this point,
It would be really good if we could improve the errors provided when
Django can't do reverse().
For example:
>>> reverse('i_dont_exist')
NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
keyword arguments '{}' not found.
In this case, it would be nicer to have something