Open diox opened 1 month ago
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.
Description
https://github.com/mozilla/addons/issues/15012 introduced soft-blocks by adding a
soft
BooleanField
toBlockVersion
.We debated switching to a
block_type
IntegerField
instead (or probably aPositiveSmallIntegerField
) and initially resisted, in part because the migration is annoying/costly, but it has since become clear this will make our lives easier, by allowing us to have constants/choices that are simpler to deal with (we can't haveChoices
with booleans).Acceptance Criteria
Checks
┆Issue is synchronized with this Jira Task