We are planning on deploying our Web2Py application under Apache-WSGI on a 
cluster of servers all accessing the same multiple databases. Since the new 
databases will be created on the fly, as needed, we cannot predict beforehand 
how many we will end up using and, consequently, how many files will end up 
being created in DATABASES folder. As a result, I am trying to create 
sub-folders under DATABASES and set MIGRATE parameter on .define_table() call 
for a given database to <sub-folder name>/<table name>.table. Such approach 
allows me to better control the overall number of files in a single folder as 
well as make the overall picture more manageable. There is one problem with 
this approach and one question for the experts:

1. A problem - we are using Auth to authenticate users and so need to perform 
auth.define_tables(). By passing to it migrate="<sub-folder name>/", I almost 
made it create all the auth_ table files in that sub-folder, except that there 
is a typo in TOOLS.PY, line 1420 in my source code for version 1.99.7, where 
instead of expected 
    
migrate=self.__get_migrate(settings.table_cas_name, migrate),
                            
it goes
    
migrate=self.__get_migrate(settings.table_event_name, migrate),

I've fixed it in my copy and would like to request that the fix should be made 
in the official release code base as well.

2. A question - should DATABASES folder be shared among the Apache-Web2Py 
machines or should each maintain its own copy? More specifically, is there any 
locking mechanism on those .table files built specifically for the purpose of 
sharing between threads/machines? I intend to use migrate_enabled=False when 
creating an instance of DAL if I know that the tables have already been 
created, but to make sure that multiple machines won't try to create the new 
database/new sub-folder at the same time, I will probably have to build some 
locks outside DAL. Is this even the right way of thinking about this problem?

Sorry for the long-winded question. Great framework, BTW. :)

-- 



Reply via email to