|
| 1 | +============= |
| 2 | +feincms3-data |
| 3 | +============= |
| 4 | + |
| 5 | +.. image:: https://github.com/matthiask/feincms3-data/actions/workflows/tests.yml/badge.svg |
| 6 | + :target: https://github.com/matthiask/feincms3-data/ |
| 7 | + :alt: CI Status |
| 8 | + |
| 9 | + |
| 10 | +Why |
| 11 | +=== |
| 12 | + |
| 13 | +Utilities for loading and dumping database data as JSON. |
| 14 | + |
| 15 | +These utilities (partially) replace Django's built-in ``dumpdata`` and |
| 16 | + ``loaddata`` management commands. |
| 17 | + |
| 18 | +Suppose you want to move data between systems incrementally. In this case it |
| 19 | +isn't sufficient to only know the data which has been created or updated; you |
| 20 | +also want to know which data has been deleted in the meantime. Django's |
| 21 | +``dumpdata`` and ``loaddata`` management commands only support the former case, |
| 22 | +not the latter. They also do not including dependent objects in the dump. |
| 23 | + |
| 24 | +This package offers utilities and management commands to address these |
| 25 | +shortcomings. |
| 26 | + |
| 27 | + |
| 28 | +How |
| 29 | +=== |
| 30 | + |
| 31 | +``pip install feincms3-data``. |
| 32 | + |
| 33 | +Add ``feincms3-data`` to ``INSTALLED_APPS`` so that the included management |
| 34 | + commands are discovered. |
| 35 | + |
| 36 | +Add specs somewhere describing the models and relationships you want to dump, |
| 37 | +e.g. in a module named ``app.specs``: |
| 38 | + |
| 39 | +.. code-block:: python |
| 40 | +
|
| 41 | + from feincms3_data.data import ( |
| 42 | + specs_for_app_models, |
| 43 | + specs_for_derived_models, |
| 44 | + specs_for_models, |
| 45 | + ) |
| 46 | + from app.dashboard import models as dashboard_models |
| 47 | + from app.world import models as world_models |
| 48 | +
|
| 49 | +
|
| 50 | + def districts(args): |
| 51 | + pks = [int(arg) for arg in args.split(",") if arg] |
| 52 | + return [ |
| 53 | + *specs_for_models( |
| 54 | + [world_models.District], |
| 55 | + {"filter": {"pk__in": pks}}, |
| 56 | + ), |
| 57 | + *specs_for_models( |
| 58 | + [world_models.Exercise], |
| 59 | + {"filter": {"district__in": pks}}, |
| 60 | + ), |
| 61 | + *specs_for_derived_models( |
| 62 | + world_models.ExercisePlugin, |
| 63 | + {"filter": {"parent__district__in": pks}}, |
| 64 | + ), |
| 65 | + ] |
| 66 | +
|
| 67 | +
|
| 68 | + def specs(): |
| 69 | + return { |
| 70 | + "articles": lambda args: specs_for_app_models("articles"), |
| 71 | + "pages": lambda args: specs_for_app_models("pages"), |
| 72 | + "teachingmaterials": lambda args: specs_for_models( |
| 73 | + [ |
| 74 | + dashboard_models.TeachingMaterialGroup, |
| 75 | + dashboard_models.TeachingMaterial, |
| 76 | + ] |
| 77 | + ), |
| 78 | + "districts": districts, |
| 79 | + } |
| 80 | +
|
| 81 | +Add a setting with the Python module path to the specs function: |
| 82 | + |
| 83 | +.. code-block:: python |
| 84 | +
|
| 85 | + FEINCMS3_DATA_SPECS = "app.specs.specs" |
| 86 | +
|
| 87 | +
|
| 88 | +Now, to dump e.g. pages and teachingmaterials you would run:: |
| 89 | + |
| 90 | + ./manage.py f3dumpdata pages teachingmaterials > tmp/dump.json |
| 91 | + |
| 92 | +To dump the districts with the primary key of 42 and 43 you would run:: |
| 93 | + |
| 94 | + ./manage.py f3dumpdata districts:42,43 > tmp/districts.json |
| 95 | + |
| 96 | +The resulting JSON file has three top-level keys: |
| 97 | + |
| 98 | +- ``"version": 1``: The version of the dump, because not versioning dumps is a |
| 99 | + recipe for pain down the road. |
| 100 | +- ``"specs": [...]``: A list of model specs and filters (see the district |
| 101 | + filter above). |
| 102 | +- ``"objects": [...]``: A list of model instances; uses the same serializer as |
| 103 | + Django's ``dumpdata``, everything looks the same. |
| 104 | + |
| 105 | +The dumps can be loaded back into the database by running: |
| 106 | + |
| 107 | + ./manage.py f3loaddata -v2 tmp/dump.json tmp/districts.json |
| 108 | + |
| 109 | +Each dump is processed in an individual transaction. The data is first loaded |
| 110 | +into the database; at the end, data *matching* the filters but whose primary |
| 111 | +key wasn't contained in the dump is deleted from the database. |
0 commit comments