Where to put Django startup code?
I'd like to have these lines of code executed on server startup (both development and production):
from django.core import management
management.call_command('syncdb', interactive=False)
Putting it in settings.py
doesn't work, as it requires the settings to be loaded already.
Putting them in a view and accessing that view externally doesn't work either, as there are some middlewares that use the database and those will fail and not let me access the view.
Putting them in a middleware would work, but that would get called each time my app is accessed. An possible solution might be to create a middleware that does all the job and then removes itself from MIDDLEWARE_CLASSES
so it's not called anymore. Can I do that without too much monkey-patching?
python django django-middleware
add a comment |
I'd like to have these lines of code executed on server startup (both development and production):
from django.core import management
management.call_command('syncdb', interactive=False)
Putting it in settings.py
doesn't work, as it requires the settings to be loaded already.
Putting them in a view and accessing that view externally doesn't work either, as there are some middlewares that use the database and those will fail and not let me access the view.
Putting them in a middleware would work, but that would get called each time my app is accessed. An possible solution might be to create a middleware that does all the job and then removes itself from MIDDLEWARE_CLASSES
so it's not called anymore. Can I do that without too much monkey-patching?
python django django-middleware
add a comment |
I'd like to have these lines of code executed on server startup (both development and production):
from django.core import management
management.call_command('syncdb', interactive=False)
Putting it in settings.py
doesn't work, as it requires the settings to be loaded already.
Putting them in a view and accessing that view externally doesn't work either, as there are some middlewares that use the database and those will fail and not let me access the view.
Putting them in a middleware would work, but that would get called each time my app is accessed. An possible solution might be to create a middleware that does all the job and then removes itself from MIDDLEWARE_CLASSES
so it's not called anymore. Can I do that without too much monkey-patching?
python django django-middleware
I'd like to have these lines of code executed on server startup (both development and production):
from django.core import management
management.call_command('syncdb', interactive=False)
Putting it in settings.py
doesn't work, as it requires the settings to be loaded already.
Putting them in a view and accessing that view externally doesn't work either, as there are some middlewares that use the database and those will fail and not let me access the view.
Putting them in a middleware would work, but that would get called each time my app is accessed. An possible solution might be to create a middleware that does all the job and then removes itself from MIDDLEWARE_CLASSES
so it's not called anymore. Can I do that without too much monkey-patching?
python django django-middleware
python django django-middleware
asked May 6 '10 at 13:18
Attila O.Attila O.
6,80364481
6,80364481
add a comment |
add a comment |
6 Answers
6
active
oldest
votes
Write middleware that does this in __init__
and afterwards raise django.core.exceptions.MiddlewareNotUsed
from the __init__
, django will remove it for all requests :). __init__
is called at startup by the way, not at the first request, so it won't block your first user.
There is talk about adding a startup signal, but that won't be available soon (a major problem for example is when this signal should be sent)
Related Ticket: https://code.djangoproject.com/ticket/13024
Update: Django 1.7 includes support for this. (Documentation, as linked by the ticket)
4
That's a nice trick I wasn't aware of.
– Will McCutchen
May 6 '10 at 14:09
2
According to stackoverflow.com/questions/6791911/…, this can be problematic. It is suggested there to put the start-up function in urls.py
– Michael
Dec 1 '11 at 22:20
2
Both middleware and urls.py do not run the startup code for management commands. Is there a better option?
– Andrei
Feb 13 '12 at 12:13
2
@krizajB: note that this answer was written with django 1.0 or 1.1 in mind, there are currently better solutions available and maybe this solution is even not valid anymore in django 1.4. I'd update the answer with more recent techniques, but I've not done much django development recently so if someone knows a better modern technique, feel free to add it.
– KillianDS
Sep 13 '12 at 10:41
2
This doesn't seem to work in python 1.4... Any recommendations/workarounds?
– rui
Nov 7 '12 at 19:39
|
show 7 more comments
If you were using Apache/mod_wsgi for both, use the WSGI script file described in:
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Add what you need after language translations are activated.
Thus:
import sys
sys.path.insert(0, '/usr/local/django/mysite')
import settings
import django.core.management
django.core.management.setup_environ(settings)
utility = django.core.management.ManagementUtility()
command = utility.fetch_command('runserver')
command.validate()
import django.conf
import django.utils
django.utils.translation.activate(django.conf.settings.LANGUAGE_CODE)
# Your line here.
django.core.management.call_command('syncdb', interactive=False)
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
That'd look a little different as I use twod.wsgi. Also, I'd like to do this on the dev server too. And I wouldn't go as low level as apache. The idea is that I might not want to give the app developer ssh access to the server, but let him use the django admin by putting it in his startup code.
– Attila O.
May 10 '10 at 14:41
add a comment |
You can create a custom command and write your code in the handle function. details here https://docs.djangoproject.com/en/dev/howto/custom-management-commands/
Then you can create a startup script that runs the django server then executes your new custom command.
1
This is a bad choice at it relies on a wrapper script around the server startup. What if someone forgets to start the server without the script?
– KillianDS
Aug 29 '11 at 11:09
I agree with @KillianDS. Still, it is a possibility. But then you'd have to use your wrapper as an entry point to the server, which may be any platform, mod_wsgi, app engine, tornado, etc.
– Attila O.
Aug 29 '11 at 14:47
add a comment |
If you are using mod_wsgi you can put it in the wsgi start app
add a comment |
Here is how I work around the missing startup signal for Django:
https://github.com/lsaffre/djangosite/blob/master/djangosite/models.py
The code that is being called there is specific to my djangosite project, but the trick to get it called by writing a special app (based on an idea by Ross McFarland) should work for other environments.
Luc
add a comment |
In Django 1.7+ if you want to run a startup code and,
1. Avoid running it in migrate, makemigrations, shell sessions, ...
2. Avoid running it twice or more
A solution would be:
file: myapp/apps.py
from django.apps import AppConfig
def startup():
# startup code goes here
class MyAppConfig(AppConfig):
name = 'myapp'
verbose_name = "My Application"
def ready(self):
import os
if os.environ.get('RUN_MAIN'):
startup()
file: myapp/__init__.py
default_app_config = 'myapp.apps.MyAppConfig'
This post is using suggestions from @Pykler and @bdoering
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2781383%2fwhere-to-put-django-startup-code%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
Write middleware that does this in __init__
and afterwards raise django.core.exceptions.MiddlewareNotUsed
from the __init__
, django will remove it for all requests :). __init__
is called at startup by the way, not at the first request, so it won't block your first user.
There is talk about adding a startup signal, but that won't be available soon (a major problem for example is when this signal should be sent)
Related Ticket: https://code.djangoproject.com/ticket/13024
Update: Django 1.7 includes support for this. (Documentation, as linked by the ticket)
4
That's a nice trick I wasn't aware of.
– Will McCutchen
May 6 '10 at 14:09
2
According to stackoverflow.com/questions/6791911/…, this can be problematic. It is suggested there to put the start-up function in urls.py
– Michael
Dec 1 '11 at 22:20
2
Both middleware and urls.py do not run the startup code for management commands. Is there a better option?
– Andrei
Feb 13 '12 at 12:13
2
@krizajB: note that this answer was written with django 1.0 or 1.1 in mind, there are currently better solutions available and maybe this solution is even not valid anymore in django 1.4. I'd update the answer with more recent techniques, but I've not done much django development recently so if someone knows a better modern technique, feel free to add it.
– KillianDS
Sep 13 '12 at 10:41
2
This doesn't seem to work in python 1.4... Any recommendations/workarounds?
– rui
Nov 7 '12 at 19:39
|
show 7 more comments
Write middleware that does this in __init__
and afterwards raise django.core.exceptions.MiddlewareNotUsed
from the __init__
, django will remove it for all requests :). __init__
is called at startup by the way, not at the first request, so it won't block your first user.
There is talk about adding a startup signal, but that won't be available soon (a major problem for example is when this signal should be sent)
Related Ticket: https://code.djangoproject.com/ticket/13024
Update: Django 1.7 includes support for this. (Documentation, as linked by the ticket)
4
That's a nice trick I wasn't aware of.
– Will McCutchen
May 6 '10 at 14:09
2
According to stackoverflow.com/questions/6791911/…, this can be problematic. It is suggested there to put the start-up function in urls.py
– Michael
Dec 1 '11 at 22:20
2
Both middleware and urls.py do not run the startup code for management commands. Is there a better option?
– Andrei
Feb 13 '12 at 12:13
2
@krizajB: note that this answer was written with django 1.0 or 1.1 in mind, there are currently better solutions available and maybe this solution is even not valid anymore in django 1.4. I'd update the answer with more recent techniques, but I've not done much django development recently so if someone knows a better modern technique, feel free to add it.
– KillianDS
Sep 13 '12 at 10:41
2
This doesn't seem to work in python 1.4... Any recommendations/workarounds?
– rui
Nov 7 '12 at 19:39
|
show 7 more comments
Write middleware that does this in __init__
and afterwards raise django.core.exceptions.MiddlewareNotUsed
from the __init__
, django will remove it for all requests :). __init__
is called at startup by the way, not at the first request, so it won't block your first user.
There is talk about adding a startup signal, but that won't be available soon (a major problem for example is when this signal should be sent)
Related Ticket: https://code.djangoproject.com/ticket/13024
Update: Django 1.7 includes support for this. (Documentation, as linked by the ticket)
Write middleware that does this in __init__
and afterwards raise django.core.exceptions.MiddlewareNotUsed
from the __init__
, django will remove it for all requests :). __init__
is called at startup by the way, not at the first request, so it won't block your first user.
There is talk about adding a startup signal, but that won't be available soon (a major problem for example is when this signal should be sent)
Related Ticket: https://code.djangoproject.com/ticket/13024
Update: Django 1.7 includes support for this. (Documentation, as linked by the ticket)
edited Jun 25 '14 at 3:09
Nick Merrill
1,04811319
1,04811319
answered May 6 '10 at 13:30
KillianDSKillianDS
14.4k35161
14.4k35161
4
That's a nice trick I wasn't aware of.
– Will McCutchen
May 6 '10 at 14:09
2
According to stackoverflow.com/questions/6791911/…, this can be problematic. It is suggested there to put the start-up function in urls.py
– Michael
Dec 1 '11 at 22:20
2
Both middleware and urls.py do not run the startup code for management commands. Is there a better option?
– Andrei
Feb 13 '12 at 12:13
2
@krizajB: note that this answer was written with django 1.0 or 1.1 in mind, there are currently better solutions available and maybe this solution is even not valid anymore in django 1.4. I'd update the answer with more recent techniques, but I've not done much django development recently so if someone knows a better modern technique, feel free to add it.
– KillianDS
Sep 13 '12 at 10:41
2
This doesn't seem to work in python 1.4... Any recommendations/workarounds?
– rui
Nov 7 '12 at 19:39
|
show 7 more comments
4
That's a nice trick I wasn't aware of.
– Will McCutchen
May 6 '10 at 14:09
2
According to stackoverflow.com/questions/6791911/…, this can be problematic. It is suggested there to put the start-up function in urls.py
– Michael
Dec 1 '11 at 22:20
2
Both middleware and urls.py do not run the startup code for management commands. Is there a better option?
– Andrei
Feb 13 '12 at 12:13
2
@krizajB: note that this answer was written with django 1.0 or 1.1 in mind, there are currently better solutions available and maybe this solution is even not valid anymore in django 1.4. I'd update the answer with more recent techniques, but I've not done much django development recently so if someone knows a better modern technique, feel free to add it.
– KillianDS
Sep 13 '12 at 10:41
2
This doesn't seem to work in python 1.4... Any recommendations/workarounds?
– rui
Nov 7 '12 at 19:39
4
4
That's a nice trick I wasn't aware of.
– Will McCutchen
May 6 '10 at 14:09
That's a nice trick I wasn't aware of.
– Will McCutchen
May 6 '10 at 14:09
2
2
According to stackoverflow.com/questions/6791911/…, this can be problematic. It is suggested there to put the start-up function in urls.py
– Michael
Dec 1 '11 at 22:20
According to stackoverflow.com/questions/6791911/…, this can be problematic. It is suggested there to put the start-up function in urls.py
– Michael
Dec 1 '11 at 22:20
2
2
Both middleware and urls.py do not run the startup code for management commands. Is there a better option?
– Andrei
Feb 13 '12 at 12:13
Both middleware and urls.py do not run the startup code for management commands. Is there a better option?
– Andrei
Feb 13 '12 at 12:13
2
2
@krizajB: note that this answer was written with django 1.0 or 1.1 in mind, there are currently better solutions available and maybe this solution is even not valid anymore in django 1.4. I'd update the answer with more recent techniques, but I've not done much django development recently so if someone knows a better modern technique, feel free to add it.
– KillianDS
Sep 13 '12 at 10:41
@krizajB: note that this answer was written with django 1.0 or 1.1 in mind, there are currently better solutions available and maybe this solution is even not valid anymore in django 1.4. I'd update the answer with more recent techniques, but I've not done much django development recently so if someone knows a better modern technique, feel free to add it.
– KillianDS
Sep 13 '12 at 10:41
2
2
This doesn't seem to work in python 1.4... Any recommendations/workarounds?
– rui
Nov 7 '12 at 19:39
This doesn't seem to work in python 1.4... Any recommendations/workarounds?
– rui
Nov 7 '12 at 19:39
|
show 7 more comments
If you were using Apache/mod_wsgi for both, use the WSGI script file described in:
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Add what you need after language translations are activated.
Thus:
import sys
sys.path.insert(0, '/usr/local/django/mysite')
import settings
import django.core.management
django.core.management.setup_environ(settings)
utility = django.core.management.ManagementUtility()
command = utility.fetch_command('runserver')
command.validate()
import django.conf
import django.utils
django.utils.translation.activate(django.conf.settings.LANGUAGE_CODE)
# Your line here.
django.core.management.call_command('syncdb', interactive=False)
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
That'd look a little different as I use twod.wsgi. Also, I'd like to do this on the dev server too. And I wouldn't go as low level as apache. The idea is that I might not want to give the app developer ssh access to the server, but let him use the django admin by putting it in his startup code.
– Attila O.
May 10 '10 at 14:41
add a comment |
If you were using Apache/mod_wsgi for both, use the WSGI script file described in:
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Add what you need after language translations are activated.
Thus:
import sys
sys.path.insert(0, '/usr/local/django/mysite')
import settings
import django.core.management
django.core.management.setup_environ(settings)
utility = django.core.management.ManagementUtility()
command = utility.fetch_command('runserver')
command.validate()
import django.conf
import django.utils
django.utils.translation.activate(django.conf.settings.LANGUAGE_CODE)
# Your line here.
django.core.management.call_command('syncdb', interactive=False)
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
That'd look a little different as I use twod.wsgi. Also, I'd like to do this on the dev server too. And I wouldn't go as low level as apache. The idea is that I might not want to give the app developer ssh access to the server, but let him use the django admin by putting it in his startup code.
– Attila O.
May 10 '10 at 14:41
add a comment |
If you were using Apache/mod_wsgi for both, use the WSGI script file described in:
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Add what you need after language translations are activated.
Thus:
import sys
sys.path.insert(0, '/usr/local/django/mysite')
import settings
import django.core.management
django.core.management.setup_environ(settings)
utility = django.core.management.ManagementUtility()
command = utility.fetch_command('runserver')
command.validate()
import django.conf
import django.utils
django.utils.translation.activate(django.conf.settings.LANGUAGE_CODE)
# Your line here.
django.core.management.call_command('syncdb', interactive=False)
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
If you were using Apache/mod_wsgi for both, use the WSGI script file described in:
http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Add what you need after language translations are activated.
Thus:
import sys
sys.path.insert(0, '/usr/local/django/mysite')
import settings
import django.core.management
django.core.management.setup_environ(settings)
utility = django.core.management.ManagementUtility()
command = utility.fetch_command('runserver')
command.validate()
import django.conf
import django.utils
django.utils.translation.activate(django.conf.settings.LANGUAGE_CODE)
# Your line here.
django.core.management.call_command('syncdb', interactive=False)
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
answered May 8 '10 at 12:38
Graham DumpletonGraham Dumpleton
48.1k680106
48.1k680106
That'd look a little different as I use twod.wsgi. Also, I'd like to do this on the dev server too. And I wouldn't go as low level as apache. The idea is that I might not want to give the app developer ssh access to the server, but let him use the django admin by putting it in his startup code.
– Attila O.
May 10 '10 at 14:41
add a comment |
That'd look a little different as I use twod.wsgi. Also, I'd like to do this on the dev server too. And I wouldn't go as low level as apache. The idea is that I might not want to give the app developer ssh access to the server, but let him use the django admin by putting it in his startup code.
– Attila O.
May 10 '10 at 14:41
That'd look a little different as I use twod.wsgi. Also, I'd like to do this on the dev server too. And I wouldn't go as low level as apache. The idea is that I might not want to give the app developer ssh access to the server, but let him use the django admin by putting it in his startup code.
– Attila O.
May 10 '10 at 14:41
That'd look a little different as I use twod.wsgi. Also, I'd like to do this on the dev server too. And I wouldn't go as low level as apache. The idea is that I might not want to give the app developer ssh access to the server, but let him use the django admin by putting it in his startup code.
– Attila O.
May 10 '10 at 14:41
add a comment |
You can create a custom command and write your code in the handle function. details here https://docs.djangoproject.com/en/dev/howto/custom-management-commands/
Then you can create a startup script that runs the django server then executes your new custom command.
1
This is a bad choice at it relies on a wrapper script around the server startup. What if someone forgets to start the server without the script?
– KillianDS
Aug 29 '11 at 11:09
I agree with @KillianDS. Still, it is a possibility. But then you'd have to use your wrapper as an entry point to the server, which may be any platform, mod_wsgi, app engine, tornado, etc.
– Attila O.
Aug 29 '11 at 14:47
add a comment |
You can create a custom command and write your code in the handle function. details here https://docs.djangoproject.com/en/dev/howto/custom-management-commands/
Then you can create a startup script that runs the django server then executes your new custom command.
1
This is a bad choice at it relies on a wrapper script around the server startup. What if someone forgets to start the server without the script?
– KillianDS
Aug 29 '11 at 11:09
I agree with @KillianDS. Still, it is a possibility. But then you'd have to use your wrapper as an entry point to the server, which may be any platform, mod_wsgi, app engine, tornado, etc.
– Attila O.
Aug 29 '11 at 14:47
add a comment |
You can create a custom command and write your code in the handle function. details here https://docs.djangoproject.com/en/dev/howto/custom-management-commands/
Then you can create a startup script that runs the django server then executes your new custom command.
You can create a custom command and write your code in the handle function. details here https://docs.djangoproject.com/en/dev/howto/custom-management-commands/
Then you can create a startup script that runs the django server then executes your new custom command.
answered Aug 28 '11 at 10:55
EmamEmam
385312
385312
1
This is a bad choice at it relies on a wrapper script around the server startup. What if someone forgets to start the server without the script?
– KillianDS
Aug 29 '11 at 11:09
I agree with @KillianDS. Still, it is a possibility. But then you'd have to use your wrapper as an entry point to the server, which may be any platform, mod_wsgi, app engine, tornado, etc.
– Attila O.
Aug 29 '11 at 14:47
add a comment |
1
This is a bad choice at it relies on a wrapper script around the server startup. What if someone forgets to start the server without the script?
– KillianDS
Aug 29 '11 at 11:09
I agree with @KillianDS. Still, it is a possibility. But then you'd have to use your wrapper as an entry point to the server, which may be any platform, mod_wsgi, app engine, tornado, etc.
– Attila O.
Aug 29 '11 at 14:47
1
1
This is a bad choice at it relies on a wrapper script around the server startup. What if someone forgets to start the server without the script?
– KillianDS
Aug 29 '11 at 11:09
This is a bad choice at it relies on a wrapper script around the server startup. What if someone forgets to start the server without the script?
– KillianDS
Aug 29 '11 at 11:09
I agree with @KillianDS. Still, it is a possibility. But then you'd have to use your wrapper as an entry point to the server, which may be any platform, mod_wsgi, app engine, tornado, etc.
– Attila O.
Aug 29 '11 at 14:47
I agree with @KillianDS. Still, it is a possibility. But then you'd have to use your wrapper as an entry point to the server, which may be any platform, mod_wsgi, app engine, tornado, etc.
– Attila O.
Aug 29 '11 at 14:47
add a comment |
If you are using mod_wsgi you can put it in the wsgi start app
add a comment |
If you are using mod_wsgi you can put it in the wsgi start app
add a comment |
If you are using mod_wsgi you can put it in the wsgi start app
If you are using mod_wsgi you can put it in the wsgi start app
edited Aug 19 '12 at 7:36
alex
339k167766912
339k167766912
answered May 7 '10 at 15:01
Aviah LaorAviah Laor
2,75711723
2,75711723
add a comment |
add a comment |
Here is how I work around the missing startup signal for Django:
https://github.com/lsaffre/djangosite/blob/master/djangosite/models.py
The code that is being called there is specific to my djangosite project, but the trick to get it called by writing a special app (based on an idea by Ross McFarland) should work for other environments.
Luc
add a comment |
Here is how I work around the missing startup signal for Django:
https://github.com/lsaffre/djangosite/blob/master/djangosite/models.py
The code that is being called there is specific to my djangosite project, but the trick to get it called by writing a special app (based on an idea by Ross McFarland) should work for other environments.
Luc
add a comment |
Here is how I work around the missing startup signal for Django:
https://github.com/lsaffre/djangosite/blob/master/djangosite/models.py
The code that is being called there is specific to my djangosite project, but the trick to get it called by writing a special app (based on an idea by Ross McFarland) should work for other environments.
Luc
Here is how I work around the missing startup signal for Django:
https://github.com/lsaffre/djangosite/blob/master/djangosite/models.py
The code that is being called there is specific to my djangosite project, but the trick to get it called by writing a special app (based on an idea by Ross McFarland) should work for other environments.
Luc
answered Dec 26 '13 at 16:10
Luc SaffreLuc Saffre
662
662
add a comment |
add a comment |
In Django 1.7+ if you want to run a startup code and,
1. Avoid running it in migrate, makemigrations, shell sessions, ...
2. Avoid running it twice or more
A solution would be:
file: myapp/apps.py
from django.apps import AppConfig
def startup():
# startup code goes here
class MyAppConfig(AppConfig):
name = 'myapp'
verbose_name = "My Application"
def ready(self):
import os
if os.environ.get('RUN_MAIN'):
startup()
file: myapp/__init__.py
default_app_config = 'myapp.apps.MyAppConfig'
This post is using suggestions from @Pykler and @bdoering
add a comment |
In Django 1.7+ if you want to run a startup code and,
1. Avoid running it in migrate, makemigrations, shell sessions, ...
2. Avoid running it twice or more
A solution would be:
file: myapp/apps.py
from django.apps import AppConfig
def startup():
# startup code goes here
class MyAppConfig(AppConfig):
name = 'myapp'
verbose_name = "My Application"
def ready(self):
import os
if os.environ.get('RUN_MAIN'):
startup()
file: myapp/__init__.py
default_app_config = 'myapp.apps.MyAppConfig'
This post is using suggestions from @Pykler and @bdoering
add a comment |
In Django 1.7+ if you want to run a startup code and,
1. Avoid running it in migrate, makemigrations, shell sessions, ...
2. Avoid running it twice or more
A solution would be:
file: myapp/apps.py
from django.apps import AppConfig
def startup():
# startup code goes here
class MyAppConfig(AppConfig):
name = 'myapp'
verbose_name = "My Application"
def ready(self):
import os
if os.environ.get('RUN_MAIN'):
startup()
file: myapp/__init__.py
default_app_config = 'myapp.apps.MyAppConfig'
This post is using suggestions from @Pykler and @bdoering
In Django 1.7+ if you want to run a startup code and,
1. Avoid running it in migrate, makemigrations, shell sessions, ...
2. Avoid running it twice or more
A solution would be:
file: myapp/apps.py
from django.apps import AppConfig
def startup():
# startup code goes here
class MyAppConfig(AppConfig):
name = 'myapp'
verbose_name = "My Application"
def ready(self):
import os
if os.environ.get('RUN_MAIN'):
startup()
file: myapp/__init__.py
default_app_config = 'myapp.apps.MyAppConfig'
This post is using suggestions from @Pykler and @bdoering
edited Nov 21 '18 at 16:10
answered Nov 21 '18 at 16:01
Joseph BaniJoseph Bani
8011
8011
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2781383%2fwhere-to-put-django-startup-code%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown