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

autodiscover blocks syncdb #17

Open
GoogleCodeExporter opened this issue Dec 16, 2015 · 2 comments
Open

autodiscover blocks syncdb #17

GoogleCodeExporter opened this issue Dec 16, 2015 · 2 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Create a new project and add django_cron.autodiscover() to your urls.py
2. Run manage syncdb
3. You get an error saying that the cron table doesn't exist

What is the expected output? What do you see instead?
Personally I would expect autodiscover to fail silently if the tables don't
exist yet.

Original issue reported on code.google.com by [email protected] on 17 Jul 2009 at 10:23

@GoogleCodeExporter
Copy link
Author

Is this still a problem? I think I may have fixed it

Original comment by [email protected] on 28 Oct 2009 at 2:29

@GoogleCodeExporter
Copy link
Author

it was still a problem 
autodiscover launch cronScheduler.execute()
so you can have in it database access in it before it creation :
so i changed : 
            status, created = Cron.objects.get_or_create(pk=1)

            # This is important for 2 reasons:
            #     1. It keeps us for running more than one instance of the
            #        same job at a time
            #     2. It reduces the number of polling threads because they
            #        get killed off if they happen to check while another
            #        one is already executing a job (only occurs with
            #        multi-threaded servers)
            if status.executing:
                return

to : 
        try:
            status, created = Cron.objects.get_or_create(pk=1)

            # This is important for 2 reasons:
            #     1. It keeps us for running more than one instance of the
            #        same job at a time
            #     2. It reduces the number of polling threads because they
            #        get killed off if they happen to check while another
            #        one is already executing a job (only occurs with
            #        multi-threaded servers)
            if status.executing:
                return
        except:
            # stop processing because we couldn't read the database
            return

Original comment by [email protected] on 2 Nov 2011 at 3:02

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant