RE: [Rainbowportal-devel] Process review for database updates

[Mark M. <mar...@ar...>]

If I understand you correctly, Manu,  you agree we should NEVER CHANGE
AN EXISTING script file, you instead have to make the fix to a NEW
script file and update the history.xml file and the hard coded version
number.  If someone ever changes an existing script then the problem I
describe below happens.

It would be nice for the v1.0 release to have both a single large script
for new installations, and also the series of patch scripts that will
upgrade existing users.  If we can only have one of these, my preference
is to keep the patches because I want to be able to update an existing
installation.

-----Original Message-----
From: rai...@li...
[mailto:rai...@li...] On Behalf Of
manudea
Sent: Monday, May 26, 2003 10:28 AM
To: rai...@li...
Subject: R: [Rainbowportal-devel] Process review for database updates


Hi, Mark... correct.
Anyway if there is some error on script we may FIX it. And add the
correction to latest script as patch (must run multiple times without
errors) so that both old and new databases are fixed.

I think we have to make a new script that created the db at some point
to avoid all script applied for new databases.

------------------------------------
Emmanuele De Andreis
Technical Manager
DUEMETRI
Internet Solutions Provider
=20
RAINBOW PORTAL
Main portal - http://www.rainbowportal.net
Sourceforge / CVS - http://sourceforge.net/projects/rainbowportal/
Support Forums - http://www.rainbowportal.net/ASPNetForums

-----Messaggio originale-----
Da: rai...@li...
[mailto:rai...@li...] Per conto di
Mark McFarlane
Inviato: luned=EC 26 maggio 2003 7.39
A: rai...@li...
Oggetto: [Rainbowportal-devel] Process review for database updates


I need to clarify the process that occurs to upgrade an existing Rainbow
database to a new version.

Here is what I have deduced

1) User accesses http://localhost/rainbow
2) rainbow detects database is out of date using the versions table
compared to a hard coded string in the .dll
3) rainbow looks at the history.xml in rainbow/setup/scripts to
determine what patches need to be applied
4) The patches are applied to the db, and the versions table is updated
to reflect these changes

Here's some implications of this process:

1) Developers should never do ANYTHING that will be destructive to user
data in these patch files. e.g. you should NEVER delete a table without
first creating a new table and copying data.

2) Developers should NEVER edit an existing patch script in CVS. That
is, there should never be more than a single version of a xxxx.x.x.sql
update script stored in CVS.  This is required because if=20
A) a user, Sue, downloads today's code and updates her database
B) tomorrow a developer, Joe, edits a previous .sql patch
C) the next day Sue gets a new code download

In this scenario, Joe's updated patch will never be executed for user
Sue in step C because her versions table in the database says that she
has already applied this patch (which, of course, she did, she just
applied a previous version of the patch).  There is no way for Sue to
recover except to either delete her Rainbow database and start over, or
try to figure out what happened (very difficult) and then write a new
patch file, ...

--> Is my deduction correct above?

--> Are my implications correct?

--> Are there other implications?

Thanks

Mark
.....improving Rainbow documentation, one day at a time :)



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore. Now
part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Rainbowportal-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel
-


-



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore. Now
part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Rainbowportal-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel