The database connection is initialized in models/db.py (assuming you used the wizard to generate your application). Look for the line that says "db=DAL(...)", and make it select the right database according to your request, e.g. request.host, or however else you determine the configuration environment.
Alternatively, you could keep it all in the same database with a "request_tenant' field: https://groups.google.com/d/topic/web2py/CixV2qflqkk/discussion - if you add a field such as the following to a table: ... Field('request_tenant', default=request.host), ... (where the default is however you identify the specific environment) web2py will add a "and request_tenant=''+request.host+''" to every query relating to that table, and of course would insert it to new records. Effectively, this means every record in a table with such a field will only be seen when the default value of the field in this request is the same as when it was generated. (You can still get all records by either setting the default to None, or adding an "ignore_common_filter=True") On Friday, March 30, 2012 4:55:16 PM UTC-4, Alex wrote: > > Hello, > > I need to configure my data source for different instances. Currently this > is the last problem preventing me from going productive. I run my > application for multiple customer instances and of course the database > connection is different for each customer. This issue also occurs if you > have a test and a productive environment. I think this is a fairly common > use case and necessary for most real world applications, so I'm really > surprised that I didn't see any solution for this in web2py (especially > since web2py is so easy and powerful for everything else). Or did I just > miss something? > > Massimo, in case you read this, do you have an advice for me? is an > environment configuration a feature that could be added in the future? I > think that I read somewhere that web2py developers don't think this is > necessary but I really don't understand why. > > Is there a workaround for me? I have some ideas but nothing seems to be > optimal. I'd prefer to avoid dirty hacks... > > thanks, > Alex > >
