Using DAL outside of web2py

[Jim S]

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

[Jim S]

Anyone have any input on this?  Unless I'm missing something obvious it appears to be a bit of a problem.

-Jim

[Niphlod]

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.

[Jim Steil]

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

--
 
---
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 web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Niphlod]

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.

[Jim Steil]

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

[Niphlod]

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)