Id field not accepting string value anymore

[7ooL]

I has same issue as #94. I rolled back to 0.3.1 to keep my Django application functioning.

I tried 0.4.1 this morning and I get an operation error. It appears that my string id are no longer valid amnd its looking for an integer value.

I create the job like this:

scheduler.add_job(checkEnableJob,'interval', id="checkEnableJob", seconds=10,max_instances=1,replace_existing=True, coalesce=True)

Traceback (most recent call last):
  File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.7/dist-packages/django/utils/autoreload.py", line 53, in wrapper
    fn(*args, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/django/core/management/commands/runserver.py", line 110, in inner_run
    autoreload.raise_last_exception()
  File "/usr/local/lib/python3.7/dist-packages/django/utils/autoreload.py", line 76, in raise_last_exception
    raise _exception[1]
  File "/usr/local/lib/python3.7/dist-packages/django/core/management/__init__.py", line 357, in execute
    autoreload.check_errors(django.setup)()
  File "/usr/local/lib/python3.7/dist-packages/django/utils/autoreload.py", line 53, in wrapper
    fn(*args, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/django/__init__.py", line 24, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/usr/local/lib/python3.7/dist-packages/django/apps/registry.py", line 122, in populate
    app_config.ready()
  File "/home/ha/web_home_auto/homeauto/apps.py", line 16, in ready
    services.start()
  File "/home/ha/web_home_auto/homeauto/services.py", line 27, in start
    scheduler.start()
  File "/home/ha/.local/lib/python3.7/site-packages/apscheduler/schedulers/background.py", line 33, in start
    BaseScheduler.start(self, *args, **kwargs)
  File "/home/ha/.local/lib/python3.7/site-packages/apscheduler/schedulers/base.py", line 162, in start
    self._real_add_job(job, jobstore_alias, replace_existing)
  File "/home/ha/.local/lib/python3.7/site-packages/apscheduler/schedulers/base.py", line 867, in _real_add_job
    store.add_job(job)
  File "/home/ha/.local/lib/python3.7/site-packages/django_apscheduler/jobstores.py", line 201, in add_job
    job_state=pickle.dumps(job.__getstate__(), self.pickle_protocol),
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/query.py", line 447, in create
    obj.save(force_insert=True, using=self.db)
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/base.py", line 751, in save
    force_update=force_update, update_fields=update_fields)
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/base.py", line 789, in save_base
    force_update, using, update_fields,
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/base.py", line 892, in _save_table
    results = self._do_insert(cls._base_manager, using, fields, returning_fields, raw)
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/base.py", line 932, in _do_insert
    using=using, raw=raw,
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/query.py", line 1249, in _insert
    return query.get_compiler(using=using).execute_sql(returning_fields)
  File "/usr/local/lib/python3.7/dist-packages/django/db/models/sql/compiler.py", line 1395, in execute_sql
    cursor.execute(sql, params)
  File "/usr/local/lib/python3.7/dist-packages/django/db/backends/utils.py", line 98, in execute
    return super().execute(sql, params)
  File "/usr/local/lib/python3.7/dist-packages/django/db/backends/utils.py", line 66, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/usr/local/lib/python3.7/dist-packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/usr/local/lib/python3.7/dist-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/python3.7/dist-packages/django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/usr/local/lib/python3.7/dist-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/python3.7/dist-packages/django/db/backends/mysql/base.py", line 73, in execute
    return self.cursor.execute(query, args)
  File "/home/ha/.local/lib/python3.7/site-packages/MySQLdb/cursors.py", line 206, in execute
    res = self._query(query)
  File "/home/ha/.local/lib/python3.7/site-packages/MySQLdb/cursors.py", line 319, in _query
    db.query(q)
  File "/home/ha/.local/lib/python3.7/site-packages/MySQLdb/connections.py", line 259, in query
    _mysql.connection.query(self, query)
django.db.utils.OperationalError: (1366, "Incorrect integer value: 'checkEnableJob' for column 'id' at row 1")

[jcass77]

Did you run ./manage.py migrate after upgrading?

If you have pre-existing jobs defined then the migrations will take care of migrating the old name field to id for you (which is indeed a CharField in the latest version).

[7ooL]

manage.py makemigrations and manage.py migrate were both run before and after the upgrade. I just doubled checked only switching out the 0.3.1 and 0.4.1 and it still breaks. I was sure to run the run migration tools in between restarting the server.

i've even tried to have no jobs defined and create them anew on 0.4.1 and the above error happens.

[jcass77]

The latest django-apscheduler model definitions and migrations both show that DjangoJob.id is a CharField (i.e. string).

If the database that you are deploying to is still expecting this field to be an integer then something must have gone wrong with the migrations for that specific deployment at some point to cause the database schema to go out of sync.

I am not familiar with MySQL but assume that it has some sort of management application that you can use to inspect the schema directly and confirm that the field definition has in fact been updated as expected.

Closing for now as I do not see any issues specific to django-apscheduler, but please re-open if you track down an actual bug in this project's codebase.