If there was a django field for TINYINT we could use that... Maybe worth writing our own ? That would make the migration slightly faster and take less space for the future.

If there was a django field for TINYINT we could use that... Maybe worth writing our own ? That would make the migration slightly faster and take less space for the future.

With some luck it's just a couple lines of code to change since we already have a DatabaseWrapper / DatabaseOperations with custom data_types / integer_field_ranges / cast_data_types defined...

Question @diox would it be possible to migrate from PositiveSmallIntegerField to a custom TINYINT field in the future? I would prefer not to add a new field, especially a custom rolled one unless we have known/serious performance issues or if we think the migration from A -> B -> C is like wayyyy higher than that of A -> C.

Wdyt?

I would prefer avoiding migrating a table that has millions of rows over and over. The custom Tinyint field should be easy to do, we already have the basic things set up to do this (src/olympia/core/db/mysql/base.py) as we already have custom db fields (src/olympia/amo/fields.py)

@diox looking at the bloom filter and it's kind of not very much fun to try continuing on that without this so I opened a PR just now.. I see you've assigned @bakulf maybe could be used as a reference but I think having the dango integer choices field is my main ask at this point.

class BlockType(models.IntegerChoices):
    BLOCKED = 0, _('Blocked')
    SOFT_BLOCKED = 1, _('Restricted')

If this class exists and is then used by both models, then I don't really care about any other details underlying as I can rely on that enum to build out the block_type based filtering logic. wdyt?

Hello, can you please help me with some information, I don't understand exactly what I need to check. Thank you very much!

@alexandruschek this task cannot be tested. This is just an internal code change.