Re: [phpesp-dev] soma changes

[Bishop B. <ph...@id...>]

[snip]
> I propose:
> require (config_defaults.php);
> 	==> defaults, gets overwritten every new release
> require (config.php);
> 	==> your own values, never gets overwritten
> require (config_fixed.php);
> 	==> fixed parts, you can change these, but they get overwritten

Why not a configs/ directory?  Eg:

[bishop@predator tmp]$ tree configs/
configs/
|-- default.php
|-- fixed.php
`-- local.php

Or a BSD style config.d directory could be adopted, where every file  
in said directory was read?  I suppose it really depends upon the goal.


>> 	if version table in db exists ==> take that one
>> 3) show a link to take db backup if wanted
>> 4) show a link to execute the update scenario: 2.0.2==>2.0.3,
>> 2.0.3==>2.0.4, ... for this, the update db scripts need to be parsed
>> and the DB prefix added if needed
>> 5) if update ok and tables contain no prefix: show link to script for
>> prefix update, and warns it needs to be changed in the config file
>> when executed
>>
>> Any comments?
> I like the idea of allowing DB updates inside the application, we just
> need to be darn sure not to destroy anything ;-)

Personally, web-accessible db maintenance makes me nervous.  How is  
access controlled?  It doesn't seem like "administrator" is enough, as  
there are "survey" administrators and "db" administrators.  If I could  
control who could do it, different story; but if not, makes me nervous  
that Janet the survey admin gets click happy and does something  
ill-advised.

I am a proponent of Phing's dbdeploy task, which makes it trivially  
easy to patch a deployment -- in a single command -- complete with undo.

bishop

-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems