Database Migrations
Tagulous supports Django migrations.
Both SingleTagField
and TagField
work in schema and data migrations.
Tagged models will be subclasses of TaggedModel
as normal (as long as
TAGULOUS_ENHANCE_MODELS
is True
), and tag fields will work as normal.
The only difference is that tag models will be instances of BaseTagModel
and BaseTagTreeModel
rather than their normal non-base versions - but this
is just how migrations work, and it will makes no practical difference.
Adding unique columns
Migrating a model to a TagModel
or TagTreeModel
involves adding unique fields
(slug
and path
for example), which normally requires 3 separate migrations. To
simplify this process, Tagulous provides the helper method add_unique_field
to add
them in a single migration - see step 2 in Converting from to tree tags from normal tags for examples of
their use.
However, use these with care - should part of the function fail for some reason when using a non-transactional database, it won’t be able to roll back and may be left in an unmigrateable state. It is therefore recommended that you either make a backup of your database before using this function, or that you follow the steps in the official Django documentation to perform the action in 3 separate migrations.
Limitations of Django migrations
Django migrations do not support changing the tag model’s base class - for
example, changing a plain model to a TagModel
, or a TagModel
to a
TagTreeModel
). Django migrations have no way to store or apply this change,
so you will need to use the Tagulous helper operation ChangeModelBases
-
see step 3 of Converting from to tree tags from normal tags for more details, or the working
example in
0003_tree.py.
Django migrations also cannot serialise lambda expressions, so the
get_absolute_url
argument is not available during data migrations, neither
when defined on a tag field, nor when in a tag model. If you need to call this
in a data migration, it is recommended that you embed the logic into your
migration.