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

Feature/improves multiple databases support #561

Merged

Conversation

abxsantos
Copy link
Contributor

Improvement related to issue #558.

  • Added a Dockerfile.dev to ensure a standardized development environment setup
  • Improved multiple database support (read/write replicas and multiple databases)
  • Added unit test scenarios for multiple database support to the scheduler
  • Updated documentation with the has_replica key allowing better multidb support

@Koed00 Koed00 merged commit 71d4b72 into Koed00:master May 23, 2021
@Koed00
Copy link
Owner

Koed00 commented May 23, 2021

Thanks for the work on this!

@abxsantos abxsantos deleted the feature/improves-multiple-databases-support branch May 23, 2021 19:18
@abxsantos
Copy link
Contributor Author

It was a pleasure!

@mohmyo
Copy link

mohmyo commented Oct 18, 2021

I have just updated to 1.3.6 and my logs started to show a persistent error for every task or schedule run:
19:00:42 [Q] Select_for_update cannot be used outside of a transaction.

Reverted back to 1.3.5 and it is working like normal again.

I'm using ORM with different DB to read and write, defined my DB router for read and write, no replica or anything else, here is my setup:

Q_CLUSTER = {
    'name': 'background_tasks',
    'workers': 4,
    'timeout': 90,
    'daemonize_workers': False,
    'retry': 3600,
    'compress': True,
    'recycle': 100,
    'max_rss': 60000,
    'save_limit': 0,
    'queue_limit': 50,
    'bulk': 10,
    'orm': 'tasks',
    'error_reporter': {
        'sentry': {
            'dsn': config('SENTRY_DSN')
        }
    }
}

routers.py

class Django_Q_Router:
    """
    A router to control all database operations on models in the
    django_q application.
    """

    def db_for_read(self, model, **hints):
        """
        Attempts to read django_q models go to tasks.
        """
        if model._meta.app_label == 'django_q':
            return 'tasks'
        return None

    def db_for_write(self, model, **hints):
        """
        Attempts to write django_q models go to tasks.
        """
        if model._meta.app_label == 'django_q':
            return 'tasks'
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        """
        Make sure django_q app only appear in the
        'tasks' database, other apps on 'default'.
        """
        if app_label == 'django_q':
            return db == 'tasks'
        else:
            return db == 'default'

I believe this fixes the problem and ensure the correct way to do this considering all different use cases.
here: https://github.com/edthrn/django-q/pull/1/files

@Koed00

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.

3 participants