When a Lino application starts up¶
This chapter describes what happens during the startup of a Lino process.
There are four major phases in the life of a Lino process:
Application definition : while Django settings are being loaded. We see this as a separate phase because Lino does some magics there.
Database definition : while Django models are being loaded
Site startup : Django models are loaded, now Lino analyzes them and adds its own data structures.
lino.api.rt) when startup has finished.
There are three major
lino.api modules named after these
lino.api.adis available during Application Definition.
lino.api.ddis available when AD has finished, during DD and Analysis.
lino.api.rtis available when Site startup has finised.
A more detailed description follows.
The manage.py script causes the module specified by
settings.pymodule) to be imported. This might happen twice (e.g. with
runserver). Everything in
models.pymodules are loaded, the Site will "start up".
Only now everything in
The Site startup phase¶
lino.core.plugins.Plugin.on_site_startup()on each plugin
Site.do_site_startup, which does the following:
lino.core.model.Model.on_analyze()on every model.
Discover and initialize actors
lino.core.actors.Actor.after_site_setup()on each actor
lino.core.plugins.Plugin.on_ui_init()on each plugin
lino.core.plugins.Plugin.post_site_startup()on each plugin
A server startup signal for Django¶
This section is obsolete. It was for Django before 1.7.
Lino provides a solution for Django's old problem of not having an "application server startup signal", a signal to be emitted when the models cache has been populated.
About the problem¶
The problem is old:
In March 2010, wojteks suggested to call it "server_initialized" in his Django ticket #13024 ("Signal sent on application startup"). This ticket has been closed because it was "fixed in a branch which needs review. See #3591."
Django ticket #3591 ("add support for custom app_label and verbose_name") seems truly very interesting and truly very complex, but didn't get into 1.5. Obviously it's not easy to find a good solution.
Note that this is not the same problem as in Entry point hook for Django projects (2013-02-14) where Brian Rosner describes a method for "running code when Django starts". We don't want to run code when Django starts, but after Django has finished to start. The difference is important e.g. if you want to analyze all installed models.
How Lino solves it¶
The basic trick is to simply send the signal "at the end of your last app's models.py file" as described by Ross McFarland on Sun 24 June 2012.
Result is that you can now write code like the following in any models or admin module of your existing project:
from djangosite.signals import startup, receiver @receiver(startup) def my_handler(sender,**kw): # code to run exactly once per process at startup print sender.welcome_text()