From Jabber dev chat, May 22, 2009

(16:00:34) david: How could the new workshop module recognize that the pre-2.0 version is already installed during the upgrade? Is upgrade.php called even after fresh install from install.xml?
(16:08:09) Eloy: I guess you can stabilish some exact "version" to detect that, yup?
(16:08:40) Eloy: current one, for example
(16:08:52) david: hmm... so if ($version < 2009052200) and ($version > 0) { // you have 1.9 workshop }
(16:08:57) Eloy: if version < xxxxxxx then, upgrade from old. ie. normal way
(16:09:03) Eloy: ?
(16:09:13) Eloy: upgrade isn't fired on install (I think)
(16:09:34) Eloy: else all modules will be sufering that problem
(16:09:47) david: Yeah that makes sense.
(16:10:09) Eloy: so the > 0 isn't necessary IMO. just standard condition
(16:10:15) david: Is there a way how a module can safely abort its upgrade?
(16:10:28) Eloy: die; :-D
(16:10:55) david: I want to display a wanring message and let the user continue with the rest of the modules
(16:11:06) Eloy: I think exceptions are around there (not sure what means "safely")
(16:11:09) david: after Continue button for example
(16:11:15) Eloy: in the middle?
(16:11:30) david: safely === not to stop the upgrade process of the rest of moodle
(16:11:37) david: not middle
(16:11:41) david: at the start
(16:11:46) Eloy: but message + button = stop
(16:11:53) Eloy: message = continue, np there.
(16:11:55) david: Hmm...
(16:12:00) Eloy: but the button...
(16:12:19) Eloy: what's the idea beyond it?
(16:12:39) david: While new workshop is in the alpha
(16:12:49) Eloy: yes?
(16:13:51) david: I want to allow testers test it even before the migration code (1.9->2.0) is ready. So if they have some  1.9 workshop installed, I want to display "You have to uninstall the current module"
(16:14:17) Eloy: ah
(16:14:18) david: or even if they already have some 2.0 from previous tests
(16:14:45) Eloy: we haven't used that approach ever, afaik
(16:14:46) david: so I will start with upgrade.php after a feature freeze
(16:14:59) david: okay
(16:15:22) david: I will describe it in the instructions for alpha testers
(16:16:26) Eloy: i.e head is broken (by definition). So don't worry. Avoid any upgrade step to be introduced (only install.xml) + doc it for testers and that's all.
(16:16:34) david: That is all because of in the alpha stage, the install.xml is still subject of possible change
(16:16:51) Eloy: yup, yup, but....
(16:17:00) Eloy: uhm
(16:17:07) Eloy: What about
(16:17:13) david: ?yes?
(16:17:28) ***david is scared
(16:17:46) Eloy: 1) create initial xml
2) create initial upgrade step calling empty workshop_upgrade_from_19()
(16:18:02) Eloy: and then continue with normal development where:
(16:18:19) Eloy: EACH change in install.xml means 1 upgrade step is necessary
(16:18:28) Eloy: (standard behaviour)
(16:18:54) Eloy: and then... some day... you'll fill the workshop_upgrade_from_19() function
(16:20:27) Eloy: btw... in that function you can include something like:

if (table_exists('some_old_workshop_table')) {
   error ('you need to delete old ws module before using this one');
}
(16:21:00) Eloy: and then replace it by proper upgrade code later,
(16:21:01) Eloy: uhm
(16:21:03) Eloy: nah!
(16:21:11) Eloy: that will break too, for sure
(16:22:04) Eloy: you need to provide proper upgrade steps from old structure to new one since day 0 of development
(16:22:16) Eloy: no matter of the migration of the data.
(16:22:20) david: I will postpone this issue for now. Alpha testing to be done on a fresh HEAD (ie without legacy workshop code)
(16:22:57) Eloy: what about to move all current tables to new ones, keeping them apart?
(16:23:09) david: ?
(16:23:11) Eloy: in very first upgrade step
(16:23:30) Eloy: rename_table (ws_xx, oldws_xx)
(16:23:36) Eloy: that could work
(16:23:42) david: that is my plan
(16:23:48) Eloy: as 1st step in upgrade, with todays date
(16:23:54) david: 1) rename legacy tables
(16:23:57) Eloy: yo already rename all the tables
(16:24:09) david: 2) install new ones from the install.xml
(16:24:21) david: 3) iterate thru old data and populate new tables
(16:24:24) Eloy: ?
(16:24:35) Eloy: in upgrade you must not install from install.xml
(16:24:47) david: Why not?
(16:24:58) Eloy: you must have one upgrade.php script with all the changes
(16:25:30) Eloy: because installl!!
(16:25:37) Eloy: is going to change along the time!!!!
(16:25:45) david: oh
(16:25:47) david: I see
(16:25:51) Eloy: and you want to install one snapshot of today
(16:25:54) Eloy: (y)
(16:26:38) david: hmm... so I will need some utility that converts the initial install.xml to the upgrade code
(16:26:48) Eloy: so, so can, safely, today, introduce 1 upgrade step:
1) doing the renaming
2) creating the initial new tables
(16:26:57) Eloy: yes, that already exists!
(16:27:04) Eloy: xmldb editor does it for you!
(16:27:05) david: does it?
(16:27:10) Eloy: yes, table by table
(16:27:11) david: I know it does
(16:27:16) david: oh yes
(16:27:18) david: ?
(16:27:24) Eloy: ? what?
(16:27:27) david: I have used field by field so far
(16:27:39) Eloy: ah, it's also forwhole tables with indexes....
(16:27:48) david: briliant
(16:27:49) Eloy: (y)
(16:28:09) Eloy: oh, sorry, gtg again... ciao :-)
(16:28:13) david: your code will save me hours of boring copy&paste work ;-)
(16:28:42) david: My students graduated yesterday and I am invited to their party tonight - got to go as well (party)