On Jan 10, 2012, at 7:32 AM, Jim Steil wrote:

> Thank Jonathan, I didn't realize that it would be created automatically.  
> I'll just keep 'databases' out of the repo altogether then.

For the benefit of other readers, the issue that Jim is referring to is that 
hg, like many source-management systems, doesn't track directories per se, only 
files, so in particular it will never have an empty directory in a repository. 
For this and related reasons, web2py makes sure that the following set of 
application subdirectories exists:

('models', 'views', 'controllers', 'databases', 'modules', 'cron', 'errors', 
'sessions', 'languages', 'static', 'private', 'uploads')

(web2py does try to be efficient about this test, so that it doesn't have to 
explicitly look for the directories on each request; ordinarily the actual test 
will happen only on the first request, so the normal overhead is negligible.)



> 
>    -Jim
> 
> On 1/10/2012 9:25 AM, Jonathan Lundell wrote:
>> On Jan 10, 2012, at 6:04 AM, Jim Steil wrote:
>> 
>>> I'm looking for input on how people manage their database connection when 
>>> setting up your app in a Mercurial repository.
>>> 
>>> If I just add my app and db.py to my repository, then every time I setup a 
>>> different development machine to access it, the app will, by default, point 
>>> to the same database.  But, this database connection isn't correct when I'm 
>>> working on my laptop or from a home workstation and therefore, I need a 
>>> different way to specify my db connection info.
>>> 
>>> The solution I've come up with is to have a config file (using configobj) 
>>> hold my db information, and read it in db.py to get the info.  But, then 
>>> this causes even more overhead on each request.
>>> 
>>> Also, what do you do about your databases sub-directory?  I would think 
>>> that I don't want to track any changes there, but when my repo gets cloned 
>>> an empty databases directory should be placed there.
>> web2py should create the databases subdirectory for you if it's not there 
>> (at the beginning of the first request).


Reply via email to