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] > <javascript:>>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. >> 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.
