Ok great! Thanks for the advice. I already made the changes so I already don't depend on having to make a request with migrate=True. I tested it and it works ok: from my main application I connect to the secondary app's database and I use .executesql() to make the changes I need before upgrading the app's code.
One more question: should I run the app once with fake_migrate=True? After manually performing the database migration and updating the app's code, it works great. I mean, the database migration involved creating and deleting some table fields, those changes were made using .executesql(). After that, I updated the app's code, including models/db.py which already has those changes in its definitions. At this point, although the application works great, the files inside /databases/ folder are not up to date. So, should I run the app one with fake_migrate=True? Or I don't need it anymore as I'm going to perform manually database migrations from now on? Thanks in advance! Best regards, Lisandro El martes, 28 de noviembre de 2023 a la(s) 10:06:52 UTC-3, Carlos Correia escribió: > Às 11:34 de 28/11/23, Lisandro escreveu: > > Hey there! > I have several web2py apps running, and one of them acts as the main one, > taking care of mantainance and upgrading the apps when needed. Sometimes > the upgrade requires a database migration. > > All the process is controlled by the main app, which takes the app that > needs to be upgraded and does this: > 1) Puts the app in maitenance mode (this is, returns http 503 to any > requests that doesn't come from localhost) > 2) Upgrades the app's code. > 3) Sets migrate=True > 4) Uses requests module to perform a GET so the migration is done in the > database app. > 5) Sets migrate=False > 6) Reactivates the app to serve any request. > > The problem I, > > > 'm facing with this technique is that some migrations take a lot of time > (sometimes because there is a lot of changes, some other times because it's > a small change in a really big database). In this cases, using requests to > perform a GET isn't ideal because it hits the timeout (a normal timeout set > for any http request). > > Is there any way to perform the database migration from outside the app > where the database is defined that doesn't involve using http requests? > > Thanks in advance! > Warm regards, > Lisandro > > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+un...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/web2py/33dd2781-ad2d-4f21-b458-ff54ee665723n%40googlegroups.com > > <https://groups.google.com/d/msgid/web2py/33dd2781-ad2d-4f21-b458-ff54ee665723n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > Hi, > > > With complex databases I recomend using a SQL script or executing the > required SQL commands from Web2py, via db.executesql(), in particular in > the case theres is also data changes associated. > > Regards, > > Carlos Correia > ========================= > MEMÓRIA PERSISTENTE > GSM: 917 157 146 (Signal) > e-mail: ge...@memoriapersistente.pt > URL: http://www.memoriapersistente.pt > > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/web2py/2fcf96d4-27e6-481c-b540-003b0c34be04n%40googlegroups.com.
