Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

offer MYSQL_COMPATIBILITY setting to remove unique from the model #267

Merged
merged 8 commits into from
May 25, 2024
Merged

offer MYSQL_COMPATIBILITY setting to remove unique from the model #267

merged 8 commits into from
May 25, 2024

Conversation

tuky
Copy link
Contributor

@tuky tuky commented May 15, 2024

Fixes #266. Funny enough I just saw the commit with the swappable model and it seems possible to do this now:

class CustomFCMDevice(AbstractFCMDevice):
    registration_id = models.CharField(  # https://github.com/xtrinch/fcm-django/issues/266
        verbose_name="Registration token",
        unique=True,
        max_length=600,  # https://stackoverflow.com/a/64902685 better to be safe than sorry
    )

    class Meta(OriginalFCMDevice.Meta):
        pass

with setting FCM_DJANGO_FCMDEVICE_MODEL = '...CustomFCMDevice'.

docs/index.rst Outdated
-------------------
MySQL has a limit for indices and therefore the `registration_id` field cannot be made unique in MySQL.
We detect the database backend and remove the unique constraint for MySQL in the migration files. However,
to ensure that the constraint is removed from the actual model you have to add the following to your settings:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should make it clear somehow this is only an edge case and most people even if using mysql won't need this (and mention what the use case would be)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

improved it and explained my alternative solution that even lets mysql users enjoy an indexed registration_id

),
]
]
if not SETTINGS["MYSQL_COMPATIBILITY"]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why explicitly check this? It should skip it if it's mysql anway?

Copy link
Contributor Author

@tuky tuky May 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make makemigrations happy. After adding

FCM_DJANGO_SETTINGS = {
    'MYSQL_COMPATIBILITY': True,
}

to the default test settings:

1st execution of makemigrations is with the check.
2nd execution is without it.

image

@tuky
Copy link
Contributor Author

tuky commented May 22, 2024

btw, i would be happy with only merging the readme part regarding a custom model and ditch the code & setting part. for us the custom model is enough as soon as it's released.

@xtrinch
Copy link
Owner

xtrinch commented May 25, 2024

I wouldn't want everyone to have to migrate to custom model because of this and there seems to be a lot of people having issues with this.

@xtrinch
Copy link
Owner

xtrinch commented May 25, 2024

Fixes #266, #258

@xtrinch xtrinch closed this May 25, 2024
@xtrinch xtrinch reopened this May 25, 2024
@xtrinch xtrinch merged commit 518414f into xtrinch:master May 25, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OperationalError: "max key length is 3072 bytes" when running tests w/ MySQL w/o migrations
2 participants