Having fake_migrate_all=True kinda suggests that indeed migrate will be turned off for the occasion, else it won't be "fake" at all.
Someone should really try out all the combinations and streamline them in the chapter about fixing broken migrations in the book (I believe there's a typo in the book). If I'm not mistaken... fake_migrate in DAL sets the default for fake_migrate of tables fake_migrate_all "wins over" fake_migrate in the table and in the DAL migrate in DAL sets the default for migrate of tables migrate_enabled "wins over" migrate in the table and in the DAL but... fake_migrate in tables is "turned on" only when migrate=True (that's because web2py just skips all the logic of accessing the .table files if migrate=False to speed up "production" apps) Given that fake_migrate "needs" to access .table files (merely overwriting them) it doesn't work with migrate=False (hence, didn't work in your case with migrate_enabled=False) On Thursday, August 22, 2013 9:43:11 PM UTC+2, Jim S wrote: > > Hey, just got it working. My problem was that in my DAL init I had > migrate=False and migrate_enabled=False. Once I removed them it all began > working with fake_migrate_all=True. > > Thanks for the help! > > -Jim > > > On Thu, Aug 22, 2013 at 2:37 PM, Niphlod <[email protected] > <javascript:>>wrote: > >> I consider a "best practice" in the need of auto_import to have .table >> files in sync with the db. Either you use migrate='tablename' in order to >> let you figure out what .table files needs to be pushed from the dev to the >> prod environment or whenever a change in the models happen (and if you have >> separated envs, you know it), you run the first request with >> fake_migrate=True to align the .table files on the prod env. >> >> >> On Thursday, August 22, 2013 9:30:39 PM UTC+2, Jim S wrote: >> >>> So, what would you consider 'best practice' when you have separate >>> production and development databases. What is the way to ensure that using >>> the DAL outside of web2py with auto_import will work reliably in both >>> environments? >>> >>> -Jim >>> >>> >>> On Thu, Aug 22, 2013 at 1:21 PM, Niphlod <[email protected]> wrote: >>> >>>> if you use auto_import you HAVE to make sure that your >>>> databases/*.table files are in sync with whatever is on the database. I >>>> really don't see the "bit of a problem": if you want to leverage the >>>> auto_import facility there's no other way around it. >>>> Given the presence of fake_migrate I really don't see the point in >>>> continuing to have out-of-sync .table files. >>>> >>>> On Thursday, August 22, 2013 5:24:50 PM UTC+2, Jim S wrote: >>>>> >>>>> Anyone have any input on this? Unless I'm missing something obvious >>>>> it appears to be a bit of a problem. >>>>> >>>>> -Jim >>>>> >>>>> On Tuesday, August 20, 2013 5:26:50 PM UTC-5, Jim S wrote: >>>>>> >>>>>> I have the following scenario and am wondering how others are >>>>>> handling it. >>>>>> >>>>>> I have a dev and prod environment that I'm working with. They exist >>>>>> on different servers. In my dev environment I have migrate turned on >>>>>> for >>>>>> all tables. In prod they are turned off. >>>>>> >>>>>> I use mercurial for source control and do NOT move my >>>>>> web2py/applications/databases directory contents from dev to prod. >>>>>> >>>>>> I have reports that are called from my web2py apps in which I'd like >>>>>> to use the DAL instead of straight SQL. I get my db connection using >>>>>> the >>>>>> following: >>>>>> >>>>>> db = DAL('%s' % (infoCenterUtil.getDalString()****), >>>>>> folder='%s/%s' % (infoCenterUtil.getWeb2pyRoot(****), >>>>>> infoCenterUtil.getDalDbDir())****, >>>>>> auto_import=True) >>>>>> >>>>>> ...where my infoCenterUtil get functions return the proper >>>>>> strings/directories for the DAL connection. >>>>>> >>>>>> This works fine on my development machine but fails on production >>>>>> with errors referencing fields that I used to have in my db but are no >>>>>> longer there. Since there are no references to these fields in the >>>>>> current >>>>>> source I can only surmise that these names are coming from the files in >>>>>> the >>>>>> /databases directory of my prod installation, which are out of date >>>>>> because >>>>>> I have migrations off and do not bring that directory over when syncing >>>>>> dev >>>>>> to prod. >>>>>> >>>>>> So, I'm looking for input on how others handle this situation. Is >>>>>> this bad practice? I'd really like to get this working because of the >>>>>> simplicity of working with the DAL but if I have to go back to SQL it >>>>>> won't >>>>>> be the end of the world. >>>>>> >>>>>> Can anyone elaborate on how they would manage this? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -Jim >>>>>> >>>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "web2py-users" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/** >>>> topic/web2py/0L1LChvcj-Q/**unsubscribe<https://groups.google.com/d/topic/web2py/0L1LChvcj-Q/unsubscribe> >>>> . >>>> To unsubscribe from this group and all its topics, send an email to >>>> web2py+un...@**googlegroups.com. >>>> >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>> >>> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "web2py-users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/web2py/0L1LChvcj-Q/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
