phpesp-devel

[phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

Hi,

I changed some parts of the phpESP config:

- You can now do authenticated ldap binds when searching for the uid,
MS AD needs this (is more secure than anonymous binds anyway)

- A default config file has been added (admin/phpESP.ini.php.default),
your own changes should go into admin/phpESP.ini.php. The advantage is
that new options can be added to the default file and you don't need to
change anything to your own config file. Also a fixed part has been
added (admin/phpESP.ini.php.fixed) containing values that should not be
changed.
The sequence is:
require (phpESP.ini.php.default);
	==> defaults, gets overwritten every new release
require (phpESP.ini.php);
	==> your own values, never gets overwritten
require (phpESP.ini.php.fixed);
	==> fixed parts, you can change these, but they get overwritten
every new release


Now I also plan an easier update:
1) read config files
2) check version of phpesp in db with the one in phpESP.ini.fixed
        if version table in db doesn't exist
		==> suggest version=2.0.2, is changeable
	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?

Franky

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

Hi all,

for the database updates: the code is already in svn, and should even
work for older versions (from 1.8.2 onwards).
If you log in as administrator, you will see only one link when a db
update is needed. It is basic, but fully functional.
I haven't added the prefix script yet, that is for later.
I would appreciate some testing from you guys ...

Franky


On Sat, 29 Mar 2008 11:57:48 +0100
Franky Van Liedekerke <lie...@te...> wrote:

> Hi,
> 
> I changed some parts of the phpESP config:
> 
> - You can now do authenticated ldap binds when searching for the uid,
> MS AD needs this (is more secure than anonymous binds anyway)
> 
> - A default config file has been added (admin/phpESP.ini.php.default),
> your own changes should go into admin/phpESP.ini.php. The advantage is
> that new options can be added to the default file and you don't need
> to change anything to your own config file. Also a fixed part has been
> added (admin/phpESP.ini.php.fixed) containing values that should not
> be changed.
> The sequence is:
> require (phpESP.ini.php.default);
> 	==> defaults, gets overwritten every new release
> require (phpESP.ini.php);
> 	==> your own values, never gets overwritten
> require (phpESP.ini.php.fixed);
> 	==> fixed parts, you can change these, but they get
> overwritten every new release
> 
> 
> Now I also plan an easier update:
> 1) read config files
> 2) check version of phpesp in db with the one in phpESP.ini.fixed
>         if version table in db doesn't exist
> 		==> suggest version=2.0.2, is changeable
> 	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?
> 
> Franky
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> 

Re: [phpesp-dev] soma changes

[Matthew G. <mat...@gm...>]

For the LDAP changes, I have access to an AD that I can test against and
will give it a go next week.

On Sat, 2008-03-29 at 17:14 +0100, Franky Van Liedekerke wrote:
> Hi all,
> 
> for the database updates: the code is already in svn, and should even
> work for older versions (from 1.8.2 onwards).
> If you log in as administrator, you will see only one link when a db
> update is needed. It is basic, but fully functional.
> I haven't added the prefix script yet, that is for later.
> I would appreciate some testing from you guys ...
> 
> Franky
> 
> 
> On Sat, 29 Mar 2008 11:57:48 +0100
> Franky Van Liedekerke <lie...@te...> wrote:
> 
> > Hi,
> > 
> > I changed some parts of the phpESP config:
> > 
> > - You can now do authenticated ldap binds when searching for the uid,
> > MS AD needs this (is more secure than anonymous binds anyway)
> > 
> > - A default config file has been added (admin/phpESP.ini.php.default),
> > your own changes should go into admin/phpESP.ini.php. The advantage is
> > that new options can be added to the default file and you don't need
> > to change anything to your own config file. Also a fixed part has been
> > added (admin/phpESP.ini.php.fixed) containing values that should not
> > be changed.
> > The sequence is:
> > require (phpESP.ini.php.default);
> > 	==> defaults, gets overwritten every new release
> > require (phpESP.ini.php);
> > 	==> your own values, never gets overwritten
> > require (phpESP.ini.php.fixed);
> > 	==> fixed parts, you can change these, but they get
> > overwritten every new release
> > 
> > 
> > Now I also plan an easier update:
> > 1) read config files
> > 2) check version of phpesp in db with the one in phpESP.ini.fixed
> >         if version table in db doesn't exist
> > 		==> suggest version=2.0.2, is changeable
> > 	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?
> > 
> > Franky
> > 
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> > 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
-- 
Matthew Gregg <mat...@gm...>

Re: [phpesp-dev] soma changes

[Matthew G. <mat...@gm...>]

See below
On Sat, 2008-03-29 at 11:57 +0100, Franky Van Liedekerke wrote:
> - A default config file has been added (admin/phpESP.ini.php.default),
> your own changes should go into admin/phpESP.ini.php. The advantage is
> that new options can be added to the default file and you don't need to
> change anything to your own config file. Also a fixed part has been
> added (admin/phpESP.ini.php.fixed) containing values that should not be
> changed.
> The sequence is:
> require (phpESP.ini.php.default);
> 	==> defaults, gets overwritten every new release
> require (phpESP.ini.php);
> 	==> your own values, never gets overwritten
> require (phpESP.ini.php.fixed);
> 	==> fixed parts, you can change these, but they get overwritten
> every new release
Splitting the file in this way seems reasonable.  Wouldn't we want the
file names to be *.php, so they can't be accidentally viewable?  And
since we are renaming, I don't see any reason to keep the phpESP.ini
name.

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

> 
> Now I also plan an easier update:
> 1) read config files
> 2) check version of phpesp in db with the one in phpESP.ini.fixed
>         if version table in db doesn't exist
> 		==> suggest version=2.0.2, is changeable
See comment I made about the suggested version in my reply to the SVN
diff email.

> 	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 ;-)
> 
> Franky
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
-- 
Matthew Gregg <mat...@gm...>

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

On Sat, 29 Mar 2008 14:58:00 -0400
Matthew Gregg <mat...@gm...> wrote:

> Splitting the file in this way seems reasonable.  Wouldn't we want the
> file names to be *.php, so they can't be accidentally viewable?  And
> since we are renaming, I don't see any reason to keep the phpESP.ini
> name.
> 
> 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

Well, the idea was to make the upgrade as painless as possible, but
then again: what's in a name :) If anybody else doesn't object to a
name change?

> > Now I also plan an easier update:
> > 1) read config files
> > 2) check version of phpesp in db with the one in phpESP.ini.fixed
> >         if version table in db doesn't exist
> > 		==> suggest version=2.0.2, is changeable
> See comment I made about the suggested version in my reply to the SVN
> diff email.

See my reply in private.

> > 	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 ;-)

Indeed, but as always: one should always take a backup before doing an
upgrade, even on command line.

Franky

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

I worked on it a bit more:
Now install and upgrade of the DB is webbased, using ADODB xml format,
which makes it db independant and thus magically working for all db's
supported by adodb.
Now, using the adodb xml format, adding/changing a prefix should be very
easy to do ... next thing on my list

Franky

On Sat, 29 Mar 2008 23:25:16 +0100 Franky Van Liedekerke
<lie...@te...> wrote:

> On Sat, 29 Mar 2008 14:58:00 -0400
> Matthew Gregg <mat...@gm...> wrote:
> 
> > Splitting the file in this way seems reasonable.  Wouldn't we want
> > the file names to be *.php, so they can't be accidentally
> > viewable?  And since we are renaming, I don't see any reason to
> > keep the phpESP.ini name.
> > 
> > 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
> 
> Well, the idea was to make the upgrade as painless as possible, but
> then again: what's in a name :) If anybody else doesn't object to a
> name change?
> 
> > > Now I also plan an easier update:
> > > 1) read config files
> > > 2) check version of phpesp in db with the one in phpESP.ini.fixed
> > >         if version table in db doesn't exist
> > > 		==> suggest version=2.0.2, is changeable
> > See comment I made about the suggested version in my reply to the
> > SVN diff email.
> 
> See my reply in private.
> 
> > > 	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 ;-)
> 
> Indeed, but as always: one should always take a backup before doing an
> upgrade, even on command line.
> 
> Franky
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> 

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

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

On Sun, 30 Mar 2008 15:20:23 -0400
Bishop Bettini <ph...@id...> wrote:

> 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.

Hmm ... I'm trying to keep the changes minimal, people don't like it
when things change too hard too often ...

> >> 	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.

Well, it's completely controlable: only the superuser can do the
update. If you're able to update the files on the webserver, I think
you can be trusted to do the db updates as well, no? And a good admin
never gives out the superuser password to somebody else :)
Wether you do them via web or manually, that's exactly the same. And
there are no inputs from the user requested: because of the xml method,
the update goes completely transparant, no matter which version you
came from (the same goes for the prefix updates that are now possible).
I invite you to try it out first, before going into more details.
(I tried a 2.0.2 update: worked fine. I tried a fresh install: worked
fine).

Franky

Re: [phpesp-dev] soma changes

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

> Well, it's completely controlable: only the superuser can do the
> update. If you're able to update the files on the webserver, I think
> you can be trusted to do the db updates as well, no? And a good admin
> never gives out the superuser password to somebody else :)

I'm not sure I was clear.  The super user account has access to  
survey-oriented functionality that's unavailable to survey designers.   
That implies that the super-user still maintains surveys, just of a  
higher caliber.  With the addition of this change, that person is now  
also responsible/able to upgrade the application.

In some circumstances, great; it's needed.  But in others, it's a  
separated concern that now has no separation.  My usage falls into the  
latter category.  I maintain the software and the server, but a client  
manages the surveys (deleting, cross-tabulating, etc.): I would not  
want the client upgrading the software willy-nilly.


> Wether you do them via web or manually, that's exactly the same.
> And there are no inputs from the user requested: because of the xml method,
> the update goes completely transparant, no matter which version you
> came from (the same goes for the prefix updates that are now possible).

There _is_ a user input: initiate the upgrade.  In my usage, I don't  
want the super user initiating an upgrade.  Sure, I can one off the  
code, but it seems to me the ability to upgrade should be a capability  
that can be assigned.


> I invite you to try it out first, before going into more details.
> (I tried a 2.0.2 update: worked fine. I tried a fresh install: worked
> fine).

I'll certainly try it out. :)

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

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

On Sun, 30 Mar 2008 16:13:14 -0400
Bishop Bettini <ph...@id...> wrote:

> > Well, it's completely controlable: only the superuser can do the
> > update. If you're able to update the files on the webserver, I think
> > you can be trusted to do the db updates as well, no? And a good
> > admin never gives out the superuser password to somebody else :)
> 
> I'm not sure I was clear.  The super user account has access to  
> survey-oriented functionality that's unavailable to survey
> designers. That implies that the super-user still maintains surveys,
> just of a higher caliber.  With the addition of this change, that
> person is now also responsible/able to upgrade the application.
> 
> In some circumstances, great; it's needed.  But in others, it's a  
> separated concern that now has no separation.  My usage falls into
> the latter category.  I maintain the software and the server, but a
> client manages the surveys (deleting, cross-tabulating, etc.): I
> would not want the client upgrading the software willy-nilly.

I understand your concern, but most applications act alike (almost all
CMS's as well): there is a superuser that does the update.
Maybe here the "superuser" is in fact "application administrator". In
that case, we can always create a new user that has - so to say - DB
admin rights (DB maintanance). But for the transition period (where
people upgrade, this is a bit difficult ...
 
> > Wether you do them via web or manually, that's exactly the same.
> > And there are no inputs from the user requested: because of the xml
> > method, the update goes completely transparant, no matter which
> > version you came from (the same goes for the prefix updates that
> > are now possible).
> 
> There _is_ a user input: initiate the upgrade.  In my usage, I don't  
> want the super user initiating an upgrade.  Sure, I can one off the  
> code, but it seems to me the ability to upgrade should be a
> capability that can be assigned.

Correct, but as always: when you do an update, you alert the admin of
the application (just in case), not? But anyway, the DB admin right
should be assignable ...
 
> > I invite you to try it out first, before going into more details.
> > (I tried a 2.0.2 update: worked fine. I tried a fresh install:
> > worked fine).
> 
> I'll certainly try it out. :)

great, let me know what you like about it :)

Franky

Re: [phpesp-dev] soma changes

[Matthew G. <mat...@gm...>]

More thoughts about the DB update.  If the version that the DB reports 
is the same as the version in the code, i.e. the schema versions match,
then the DB update should do absolutely nothing.  This makes giving the
super-user the ability to do the update less "scary" and should work for
Bishop's use case no?

Bishop, you could update the phpESP code, immediately login as the super
user and do the DB update.  Then your user, super-users, could click
update all day long and nothing would happen other than a page that says
DB is already up to date.

This brings up another issue we should handle, if the schema is
mismatched, we should report on the admin side that the DB needs
updating and then on deployed survey side, that submissions cannot be
done at this time.


On Sat, 2008-03-29 at 23:25 +0100, Franky Van Liedekerke wrote:
> 
> > > Now I also plan an easier update:
> > > 1) read config files
> > > 2) check version of phpesp in db with the one in phpESP.ini.fixed
> > >         if version table in db doesn't exist
> > > 		==> suggest version=2.0.2, is changeable
> > See comment I made about the suggested version in my reply to the SVN
> > diff email.
> 
> See my reply in private.
> 
> > > 	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 ;-)
> 
> Indeed, but as always: one should always take a backup before doing an
> upgrade, even on command line.
> 
> Franky
-- 
Matthew Gregg <mat...@gm...>

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

On Sun, 30 Mar 2008 17:49:35 -0400
Matthew Gregg <mat...@gm...> wrote:

> More thoughts about the DB update.  If the version that the DB
> reports is the same as the version in the code, i.e. the schema
> versions match, then the DB update should do absolutely nothing.
> This makes giving the super-user the ability to do the update less
> "scary" and should work for Bishop's use case no?

Hi, this is already the case. Once the update is done, no second update
is possible (since the versions match). See my comment below as well.
 
> Bishop, you could update the phpESP code, immediately login as the
> super user and do the DB update.  Then your user, super-users, could
> click update all day long and nothing would happen other than a page
> that says DB is already up to date.
> 
> This brings up another issue we should handle, if the schema is
> mismatched, we should report on the admin side that the DB needs
> updating and then on deployed survey side, that submissions cannot be
> done at this time.

If the versions mismatch, the only thing you can do on the admin side
is execute the update (all other links are not visible). Once the
update is done, the update link no longer shows and everything is back
to normal.
I can add the same logic to the survey side if wanted. But what do you
normally do when updating? Maybe we should just have a file called
"disabled" or so, and as long as that file is there, all surveys appear
offline (something like "The system is undergoing an update, please be
patient"). What do you think?

Franky

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

For your info: I made a small booboo in public/phpESP.first.php and
public/signup.php, causing a config file not to be read. Is fixed now.
So before you start testing: upate to the latest svn.

Franky

On Mon, 31 Mar 2008 19:41:06 +0200
Franky Van Liedekerke <lie...@te...> wrote:

> On Sun, 30 Mar 2008 17:49:35 -0400
> Matthew Gregg <mat...@gm...> wrote:
> 
> > More thoughts about the DB update.  If the version that the DB
> > reports is the same as the version in the code, i.e. the schema
> > versions match, then the DB update should do absolutely nothing.
> > This makes giving the super-user the ability to do the update less
> > "scary" and should work for Bishop's use case no?
> 
> Hi, this is already the case. Once the update is done, no second
> update is possible (since the versions match). See my comment below
> as well. 
> > Bishop, you could update the phpESP code, immediately login as the
> > super user and do the DB update.  Then your user, super-users, could
> > click update all day long and nothing would happen other than a page
> > that says DB is already up to date.
> > 
> > This brings up another issue we should handle, if the schema is
> > mismatched, we should report on the admin side that the DB needs
> > updating and then on deployed survey side, that submissions cannot
> > be done at this time.
> 
> If the versions mismatch, the only thing you can do on the admin side
> is execute the update (all other links are not visible). Once the
> update is done, the update link no longer shows and everything is back
> to normal.
> I can add the same logic to the survey side if wanted. But what do you
> normally do when updating? Maybe we should just have a file called
> "disabled" or so, and as long as that file is there, all surveys
> appear offline (something like "The system is undergoing an update,
> please be patient"). What do you think?
> 
> Franky
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> 

Re: [phpesp-dev] soma changes

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

Quoting Franky Van Liedekerke <lie...@te...>:

> I can add the same logic to the survey side if wanted. But what do you
> normally do when updating? Maybe we should just have a file called
> "disabled" or so, and as long as that file is there, all surveys appear
> offline (something like "The system is undergoing an update, please be
> patient"). What do you think?

This is an important issue in my particular case, as at any given time  
there can be up to 30,000 unique people hitting the surveys at one  
time. In my situation, I tell Apache to redirect to a maintenance  
page, then run the update from the command line using a script that  
was previously tested on a QA server.  Usually the update implies only  
a few seconds of down-time, which is great.  Whatever process is  
chosen, it must be atomic, so create a lock file, flock() it, and run  
the update.  Might need a method to force the lock file too, just in  
case something dies (server boot)?

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

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

On Mon, 31 Mar 2008 14:51:35 -0400
Bishop Bettini <ph...@id...> wrote:

> Quoting Franky Van Liedekerke <lie...@te...>:
> 
> > I can add the same logic to the survey side if wanted. But what do
> > you normally do when updating? Maybe we should just have a file
> > called "disabled" or so, and as long as that file is there, all
> > surveys appear offline (something like "The system is undergoing an
> > update, please be patient"). What do you think?
> 
> This is an important issue in my particular case, as at any given
> time there can be up to 30,000 unique people hitting the surveys at
> one time. In my situation, I tell Apache to redirect to a
> maintenance page, then run the update from the command line using a
> script that was previously tested on a QA server.  Usually the update
> implies only a few seconds of down-time, which is great.  Whatever
> process is chosen, it must be atomic, so create a lock file, flock()
> it, and run the update.  Might need a method to force the lock file
> too, just in case something dies (server boot)?
> 
> bishop
> 

How about this:
I add the possibility to generate the SQL statements needed for the
update, so you can save this to a file and execute it manually.

That way you can update the files on your QA server, generate the SQL,
test this as usual and then go to production with it.

Let me know what you think about it ... I added this to svn now :)

Franky

Re: [phpesp-dev] soma changes

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

Quoting Franky Van Liedekerke <lie...@te...>:

> How about this:
> I add the possibility to generate the SQL statements needed for the
> update, so you can save this to a file and execute it manually.
>
> That way you can update the files on your QA server, generate the SQL,
> test this as usual and then go to production with it.
>
> Let me know what you think about it ... I added this to svn now :)

Sounds good to me!

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

Re: [phpesp-dev] soma changes

[Franky V. L. <lie...@te...>]

On Mon, 31 Mar 2008 16:14:05 -0400
Bishop Bettini <ph...@id...> wrote:

> Quoting Franky Van Liedekerke <lie...@te...>:
> 
> > How about this:
> > I add the possibility to generate the SQL statements needed for the
> > update, so you can save this to a file and execute it manually.
> >
> > That way you can update the files on your QA server, generate the
> > SQL, test this as usual and then go to production with it.
> >
> > Let me know what you think about it ... I added this to svn now :)
> 
> Sounds good to me!
> 
> bishop
> 

Hi all,

the latest changes have been done and I feel confident the current svn
is stable enough (don't worry Bishop, I fixed your 2 bugs :)
So to all: time to test, I'm planning to release the new version pretty
soon (maybe beta first, who knows ...).
I'm not quite sure what to do with the config files though ... I like
the config subdir idea the best, so unless somebody has serious
objections, it will become:

config/config.defaults.php
config/config.php
config/config.fixed.php
config/README

Franky

btw Bishop: all mails from SF to you bounce ...