Milind Shakya

Yes, please consider opening a pull request with your changes. Happy to review it and merge it if applicable, when i get sometime this week.

@hadisfr thanks for opening an issue. Is the fix suggested above, aimed towards virtualenv repo?

Doesnt `django_celery_beat` already populate the periodictask and other tasks already if the tasks are registered properly with celery 4.2?

I understand, am just thinking what models, data are you thinking of migrating. I can see that some of the tables in the new `django-celery-beat` are already populated, during the...

Rebased. @auvipy I agree in most cases, we would'nt update an existing migration and instead create a new one, but in this case, its required to update the existing migration,...

@auvipy Yes it should work since it defaults to the original max_length to maintain backwards compatibility.

@tinylambda Are you suggesting, removing the `max_length=200` restriction altogether? hmmm, not sure if that will have some other side-effects as a result.

@tinylambda i dont think the issue is with the uniqueness constraint. its with the max length value being too large for mysql.

@tinylambda I haven't had the chance to test the changes when we remove unique=True, but don't we actually want unique=True, since that will prevent PeriodicTask with duplicate names?

@tinylambda I feel that might be a bit overkill. Any issues with the current approach?