When and how you do this depends a bit on how safe it is to do updates when existing application processes are running.
Take for example an extreme case such as database migration. In the case of database migration where model/data changes are being made, you should ensure that all existing instances of the application are shutdown first. You would then run the database migration and then start up the application again. For an update such as this where the application should be shutdown, then it would normally be coordinated from outside of the web application server. In short, it is because of the need to do things in a certain order. Order is going to be important in your case as well. If your scan and the database and settings updates must be completed before application processes are started, you cannot necessarily use the service script feature. This is because it gets started up in parallel to the web application processes. As a result, the changes may not be completed in time. I do have some ideas of how you may be able to use service script, but not necessarily by itself. Before I can suggest anything, I need to know a couple of things. What is it that the web application looks up to know about the new databases? Is it that table in the main database you add the names of the connections, or is it by looking at DATABASES in settings? If by dynamic lookup of list of names at database, at what point does that occur, does it occur just once for the life of the process, or on each request as necessary? I guess I am trying to understand what is the critical point which marks when everything is in place. Hopefully you understand what I am asking. Graham > On 25 Apr 2016, at 7:07 PM, Julien Delafontaine <[email protected]> wrote: > > The files in the folder are sqlite databases. Each of them defines a > "connection" in Django settings, that one can use through the ORM using > "django.db.connections". Settings are loaded when the app starts. > > So there is no way I think that I can use the ORM with these sqlite databases > without restarting the app when I add a new one, in order the ORM to be aware > that there is a new connection available. > > I first fill my main database with the names of the connections, then add > each of them to the settings.DATABASES, then the app starts... I know, it > looks bad, but I couldn't find a better way. > > > Le lundi 25 avril 2016 15:27:24 UTC+2, Jason Garber a écrit : > Hi Julien, > > You can create another background process with it's own settings using > WSGIStartupScript and a separate WSGIProcessGroup with 1 process and 1 thread. > > However it seems odd that you would do this on startup and put it in a > database. Why does it need done on each startup if it is in the DB? > > Perhaps just create another table in the db with a status: empty, scanning, > filled. > > On a timed interval or startup you could basic locking to lock that table, > and only one process/thread would get to do.the work. > > J > > On Apr 25, 2016 9:13 AM, "Julien Delafontaine" <mura...@ <>gmail.com > <http://gmail.com/>> wrote: > Hi again, > > It seems trememdously hard in Django to run code only once when the app > starts, instead it is executed once per process. I tried wsgi.py, > settings.py, apps.py, and many others. Is it a good idea to use the > --service-script option for that purpose? > > I want to scan a folder when the app starts to update my database according > to the files found there. > Like > --service-script scan myapp/scripts/scan_folders.py > even if I don't use the service anymore after that. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to modwsgi+u...@ <>googlegroups.com <http://googlegroups.com/>. > To post to this group, send email to mod...@ <>googlegroups.com > <http://googlegroups.com/>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
