courtesy of mypy
Details
- Reviewers
ardumont - Group Reviewers
Reviewers - Commits
- rDDEP260de319ea1a: models: add required on_delete kwarg to ForeignKey
Diff Detail
- Repository
- rDDEP Push deposit
- Branch
- bug/missing-fk-on-delete
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 7930 Build 11420: tox-on-jenkins Jenkins Build 11419: arc lint + arc unit
Event Timeline
Build is green
See https://jenkins.softwareheritage.org/job/DDEP/job/tox/178/ for more details.
I'm not sure what this does.
Also, when modifying the models, you need to call a routine which generates the migration scripts (corresponding to the change you made in the model).
To sum up [1]:
make db-prepare
That migration script should be commited as well.
It's dev executed with make db-migrate (in production it's executed though django tools).
[1] https://docs.softwareheritage.org/devel/swh-deposit/dev-info.html#schema
[2] https://docs.softwareheritage.org/devel/swh-deposit/sys-info.html#migrate-bootstrap-the-db-schema
I'm not sure what this does.
From [1] Prevent deletion of the referenced object by raising ProtectedError, a subclass of django.db.IntegrityError.
ok then ;)
There is still the migration part to do though.
[1] https://docs.djangoproject.com/en/2.2/ref/models/fields/#django.db.models.PROTECT
Sure, I'll do that, but first I need validation of what you (or anyone else who is more familiar than me with the deposit constraints) want to happen when this referential integrity constraint is violated—specifically, when (and if) the parent deposit of a given deposit is removed from the DB.
What I've picked will make the ORM refuse the deletion, which is the safest option. There is also the option of "doing nothing", which will still make things explode at the DB level (because we use a decent DB). Or to cascade, deleting also all children records.
Let me know what you prefer, and I'll update the diff to include the migration script.
Sure, I'll do that, but first I need validation of what you (or anyone else who is more familiar than me with the deposit constraints) want to happen when this referential integrity constraint is violated—specifically, when (and if) the parent deposit of a given deposit is removed from the DB.
To which i'm ok with ;) [1]
[1] D2031#47038
Build is green
See https://jenkins.softwareheritage.org/job/DDEP/job/tox/180/ for more details.