[Django] #34456: Add a way to set allow_cascade=True in _fixture_teardown()
Django
---------------------------------------------+------------------------
Reporter: devanubis | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 4.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------------+------------------------
We use [django-timescaledb](https://github.com/schlunsen/django-
timescaledb) as our database backend and ran into a problem with some of
our tests for django migrations on tables using timescale compression.
I [wrote up our problem on `django-timescaledb` back in
October](https://github.com/schlunsen/django-timescaledb/issues/40), but
it essentially boils down to:
* `django.test.testcases.TransactionTestCase._fixture_teardown()` calls
`django.db.backends.postgresql.operations.sql_flush()` and truncates every
table at the end of tests.
* In timescaledb, compressed hypertables create "chunks" as tables with a
subset of the hypertable's data.
* Because we have foreign keys in some of our hypertables, the chunk
tables also get that foreign-key rule.
* Those chunk tables are transparent to Django, and so are not in the list
to be truncated.
* And so, the truncation fails, because the chunk tables still reference
some of the data being truncated.
The easiest solution seems to be to allow `_fixture_teardown()` to opt-in
to setting `allow_cascade=True` when truncating.
We're happy to submit a PR if this proposal gets accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/34456>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: devanubis | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 4.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by devanubis:
Old description:
> We use [django-timescaledb](https://github.com/schlunsen/django-
> timescaledb) as our database backend and ran into a problem with some of
> our tests for django migrations on tables using timescale compression.
>
> I [wrote up our problem on `django-timescaledb` back in
> October](https://github.com/schlunsen/django-timescaledb/issues/40), but
> it essentially boils down to:
>
> * `django.test.testcases.TransactionTestCase._fixture_teardown()` calls
> `django.db.backends.postgresql.operations.sql_flush()` and truncates
> every table at the end of tests.
> * In timescaledb, compressed hypertables create "chunks" as tables with a
> subset of the hypertable's data.
> * Because we have foreign keys in some of our hypertables, the chunk
> tables also get that foreign-key rule.
> * Those chunk tables are transparent to Django, and so are not in the
> list to be truncated.
> * And so, the truncation fails, because the chunk tables still reference
> some of the data being truncated.
>
> The easiest solution seems to be to allow `_fixture_teardown()` to opt-in
> to setting `allow_cascade=True` when truncating.
>
> We're happy to submit a PR if this proposal gets accepted.
New description:
We use https://github.com/schlunsen/django-timescaledb as our database
backend and ran into a problem with some of our tests for django
migrations on tables using timescale compression.
I [wrote up our problem on `django-timescaledb` back in October
(https://github.com/schlunsen/django-timescaledb/issues/40) but it
essentially boils down to:
* `django.test.testcases.TransactionTestCase._fixture_teardown()` calls
`django.db.backends.postgresql.operations.sql_flush()` and truncates every
table at the end of tests.
* In timescaledb, compressed hypertables create "chunks" as tables with a
subset of the hypertable's data.
* Because we have foreign keys in some of our hypertables, the chunk
tables also get that foreign-key rule.
* Those chunk tables are transparent to Django, and so are not in the list
to be truncated.
* And so, the truncation fails, because the chunk tables still reference
some of the data being truncated.
The easiest solution seems to be to allow `_fixture_teardown()` to opt-in
to setting `allow_cascade=True` when truncating.
We're happy to submit a PR if this proposal gets accepted.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34456#comment:1>
Django
-----------------------------------+--------------------------------------
Reporter: devanubis | Owner: nobody
Component: Testing framework | Version: 4.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------
* status: new => closed
* resolution: => needsinfo
Comment:
As far as I'm aware, it's an issue in `timescaledb`, they could override
`ops.sql_flush()` and add flushing "chunks".
--
Ticket URL: <https://code.djangoproject.com/ticket/34456#comment:2>
Django
-----------------------------------+--------------------------------------
Type: Uncategorized | Status: closed
Component: Testing framework | Version: 4.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------
Changes (by Mariusz Felisiak):
* resolution: needsinfo => invalid
--
Ticket URL: <https://code.djangoproject.com/ticket/34456#comment:3>
Django
-----------------------------------+--------------------------------------
Reporter: Howard Cox | Owner: nobody
Type: Uncategorized | Status: closed
Component: Testing framework | Version: 4.2
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------
Comment (by Howard Cox):
That's fair, it's been abandoned anyway so we're considering forking it,
so can just change it.
--
Ticket URL: <https://code.djangoproject.com/ticket/34456#comment:4>