mirror of
https://github.com/peeringdb/peeringdb.git
synced 2024-05-11 05:55:09 +00:00
* remove log file writing from migration * run tests on mysql * fix tests (pt.1) * fix tests (pt.2) * fix all user_id errors in tests * Fix geocode typo * More test changes for mysql id issues * Add coverage config that defines coverage db should go inside test folder * update docs * fix mysql user * fix tests cli * add mysql collate settings * docs * fix sync * fix sync * docs * remove debug output * remove XXX * interim commit to move to dev box * mv db local, rm after run * updates for 724 * note layer error message and work around * fix travis * chown tests * more travis fixes * travis: touch Ctl/dev/.env * write coverage report to ./coverage * clean up docs * formatting Co-authored-by: Stefan Pratter <stefan@20c.com> Co-authored-by: Elliot Frank <elliot@20c.com>
680 B
680 B
Commands
Can be run from prod0
undelete
First find out the version id when the object was deleted
python manage.py pdb_reversion_inspect <reftag> <id>
VERSION: 7 (392112) - 2018-12-24T07:13:49.612Z - User: johnsmith
status: 'ok' => 'deleted'
You want the number inside the brackets (in this case 392112)
Then run the undelete command
python manage.py pdb_undelete <reftag> <id> <version id>
This will show you everthing that will be undeleted, it will run in pretend mode, nothing is committed yet.
After reviewing, run the command again with the --commit flag
python manage.py pdb_undelete <reftag> <id> <version id> --commit