DatabaseScheduler crashes on Oracle when CrontabSchedule fields contain * wildcards

[bog-a]

Environment observed:

django-celery-beat==2.9.0
celery==5.6.2
Django==6.0.6
Oracle database
python-oracledb
scheduler: django_celery_beat.schedulers:DatabaseScheduler

The database contains normal django_celery_beat_crontabschedule rows with wildcard crontab values, for example:

minute='*/5', hour='*', day_of_week='*', day_of_month='*', month_of_year='*'
minute='0', hour='*', day_of_week='*', day_of_month='*', month_of_year='*'
minute='30', hour='*', day_of_week='*', day_of_month='*', month_of_year='*'

When celery beat starts, DatabaseScheduler.enabled_models() calls _get_crontab_exclude_query(). On Oracle, the generated query attempts to cast crontab text fields such as HOUR to a number while rows still contain '*'.

Actual result:

django.db.utils.DatabaseError: ORA-01722: unable to convert string value containing '*' to a number: HOUR

The traceback goes through:

django_celery_beat.schedulers.DatabaseScheduler.enabled_models
django_celery_beat.schedulers.DatabaseScheduler._get_crontab_exclude_query
django.db.models.functions.comparison.Cast
django.db.backends.oracle

Expected result:

DatabaseScheduler should treat '*' as a valid crontab wildcard and should not issue Oracle SQL that casts wildcard crontab fields to numeric values before safely excluding or handling wildcard rows.

Impact:

Celery beat cannot start, so database-backed periodic tasks stop being scheduled.

Workaround found:

Pinning back to the following stack avoided the crash:

Django==5.1.5
django-celery-beat==2.8.1
celery==5.6.2
oracledb==2.5.1

This appears to be a regression or compatibility issue in the newer scheduler query logic for Oracle-backed databases.