Actstream unusable if you set USE_JSONFIELD to True after installation

In the migration 0002 you have:

    if not USE_JSONFIELD:
        operations = [
            migrations.RemoveField(
                model_name='action',
                name='data',
),

Consider the following use case:

• assumption USE_JSONFIELD is False by default
• You install activity-stream and run the initial migration
• You set USE_JSONFIELD to True

Now, each operation raise an SQL error because data column is missing.

If you rollback 0002 when USE_JSONFIELD is True it will not fix the problem. You need to rollback to 0001 with USE_JSONFIELD set to False then change USE_JSONFIELD to True and reroll 0002 migration.

May this condition can be removed.

Regards

[cb109]

Just ran into this today. We’ve been using the library for a year and now want to extend usage by attaching data via a JSONField. Docs say

This behavior is disabled by default but just set ACTSTREAM_SETTINGS[‘USE_JSONFIELD’] = True in your settings.py to enable it.

Well that is only true if you never ran migrations in the first place, it’s basically an invitation to get stuck and I think both docs as the process itself can be improved. How about removing this 0002 migration altogether, what purpose does it have? Is it an optimization, sparing us a column in the database? No big deal for me honestly.

[cb109]

This would help with people changing their mind whether they want to use the data field later on. However they’d still have to make the right decision in choosing an implementation in the first place, so that the field type does not have to be changed later. That would require an installation of one of the JSONField packages, making it a hard dependency instead of an optional one. I think the default case should cater to most people and I believe that this would be an improvement over the current approach.

I would say USE_JSONFIELD is obsolete and can go away, instead we always create a data field during initial migrations and make it a jsonfield.fields.JSONField by default (or optionally a django_mysql.models.json.JSONField, depending on installed packages). That would make django-jsonfield a default requirement, which I think is okay (it’s a pure python package in the end).

Migration 0002 could be removed. Maybe it would be possible to prompt the user during initial migrations, explaining the decision he is about to make for the JSONField implementation. Not sure if this “interrupting” migration is something feasible to do. Other than that, any changes that need to be done later would be covered once the swappable models are in place, allowing to migrate field types inside your own application at a later time.

I may have missed something, so other opinions on this would be helpful.