simplenews_update_6010() not applied...

I thought the update system was smarter, but it is not. But the problem is not so big. update_6009 (and 6010) originate from this issue: http://drupal.org/node/767556 which is just about a schema mismatch not about malfunction. The easiest solution I see is to continue with update_620x in the 6.x-1.x branch and use a higher number range (i.e. 625x) for the 6.x-2.x branch. The update_6200 in the current 6.x-2.x branch should be repeated (and made conditional) as update_6250.

as you know in version 1.2 and 1.3 (in case of updating form an realy old version) the simplenews_update_6010 and simplenews_update_6011 aren't executed, since they are after simplenews_update_6200 in the source code (http://drupal.org/node/804252).

The order is changed in the dev-Version, but for simplenews version 6.x-1.3 in the system table the schema_version is 6200 and simplenews_update_6010 and simplenews_update_6011 won't be excuted either.

the only solution is to update the numbers, see the attached patch.

Thomas, if we update this to a more recent number, many users will see errors (if the update was already executed).
So if we renumber the patch, we also should check if it already was executed (in a DB independent way).

I don't want to provide errors for regular updaters.

I hope you see a better way.

This is becoming ugly now.
There happened some mess with the 6200 number in 6--1(-1) already. In addition we already added some upgrade hooks to 6--2 branch.

I decided to fix 6--1 cleanly and break the upgrade for the -dev only users of the branch 6--2. While all upgrades will proceed cleanly starting from 6--1 -- if a user already used 6--2 branch he will see errors. However, they won't result in something broken. I can't fix the situation any better now.

Can someone please try a 6--1-1 install to 6--1-dev upgrade to and then 6--2-dev please (after the commit delay went into tar-gz or checkout the cvs version.) Sure it also would be of interest to know if this also works from 6--1-2 and 6--1-3.

Thanks for any inputs.

hi,

i tested 6.x-1.x-dev; 6.x-2.x-dev and HEAD from CVS a few hours ago (on request of miro_dietiker).

The actual versions work as expected.

No more schema errors.

Thank you, Thomas!
How about direct updates from the obsolete previous releases (6--1-1, 6--1-2, 6--1-3 directly)?
Just want to make sure all cases work cleanly in the current situation.
It is really needed to check this because those different cases are really different in how the schema looks like as a starting point. (And in addition we have moved updates around between versions.)

OK tested upgrade cycles from 6--1 (6--1-1, 6--1-3) in deep detail and it seems all result in the same situation - which is generally fine.
However 6--2 still misses some updates in the schema after upgrade, namely: simplenews_snid_tid.timestamp and simplenews_snid_tid.source
I've updated the .install procedure once more. All resulting schemas for 6--2 should now exactly match the schema after a clean install. (However users already using 6--2-dev that upgraded should tell update.php to reexecute 6251 update to make the schema complete. We won't fix the errors in this situation because it was -dev only.)

Please test (again). ;-)

I have updated Simplenews 6.x-2.x-dev from the 2010-Aug-07 to the 2010-Aug-22 snapshot and received the following error on the DB update (via 'drush updb'):

The following updates are pending:

 simplenews module                                                                                                       
 6251 - Add fields 'status', 'timestamp', 'source' to 'simplenews_snid_tid' table.   First update of DRUPAL-6--2 branch. 
 6252 - Add 'sent_subscriber_count' field to 'simplenews_newsletters' table.                                             


Do you wish to run all pending updates? (y/n): y
Executing simplenews_update_6251                                                                                           [success]
WD php: Duplicate column name 'status'                                                                                       [error]
query: ALTER TABLE simplenews_snid_tid ADD `status` SMALLINT NOT NULL DEFAULT 1 in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
WD php: Duplicate column name 'timestamp'                                                                                    [error]
query: ALTER TABLE simplenews_snid_tid ADD `timestamp` INT unsigned NOT NULL DEFAULT 0 in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
WD php: Duplicate column name 'source'                                                                                       [error]
query: ALTER TABLE simplenews_snid_tid ADD `source` VARCHAR(24) NOT NULL DEFAULT '' in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
ALTER TABLE {simplenews_snid_tid} ADD `status` SMALLINT NOT NULL DEFAULT 1                                                   [error]
ALTER TABLE {simplenews_snid_tid} ADD `timestamp` INT unsigned NOT NULL DEFAULT 0                                            [error]
ALTER TABLE {simplenews_snid_tid} ADD `source` VARCHAR(24) NOT NULL DEFAULT ''                                     [error]
Executing simplenews_update_6252                                                                                           [success]
WD php: Duplicate column name 'sent_subscriber_count'                                                                        [error]
query: ALTER TABLE simplenews_newsletters ADD `sent_subscriber_count` INT NOT NULL DEFAULT 0 in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
ALTER TABLE {simplenews_newsletters} ADD `sent_subscriber_count` INT NOT NULL DEFAULT 0                                      [error]
Duplicate column name 'status'                                                                                     [error]
query: ALTER TABLE simplenews_snid_tid ADD `status` SMALLINT NOT NULL DEFAULT 1 in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
Duplicate column name 'timestamp'                                                                                  [error]
query: ALTER TABLE simplenews_snid_tid ADD `timestamp` INT unsigned NOT NULL DEFAULT 0 in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
Duplicate column name 'source'                                                                                     [error]
query: ALTER TABLE simplenews_snid_tid ADD `source` VARCHAR(24) NOT NULL DEFAULT '' in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
Duplicate column name 'sent_subscriber_count'                                                                      [error]
query: ALTER TABLE simplenews_newsletters ADD `sent_subscriber_count` INT NOT NULL DEFAULT 0 in
/usr/share/drupal/includes/database.mysql-common.inc on line 298.
An error occurred at function : drush_core_updatedb_batch_process                                                            [error]
'all' cache was cleared                                                                                                    [success]
An error occurred at function : drush_core_cache_clear                                                                       [error]
Finished performing updates.                                                                                                    [ok]
An error occurred at function : drush_core_updatedb                                                                          [error]

Since the 6--2 updates where broken (and we never released 6--2 anyway) this is (again) by intention.

Your result is stable and clean however we don't have any (db independent) information available to check if the updates are needed or not from schema or DB layer...

So all that already run the 6--2-dev release will see those errors - which won't result in anything broken.
This was needed due to previously broken naming of updates and the fact that not all update sequences have been tested.

Note that as of e.g. Drupal core upgrade policy beta is guaranteed to be upgrade stable and nothing before (like alpha or dev). So we're at a very good level of quality to support upgrades in -dev (with only some error messages ;-) ).

nJoy

Yes, no problem here - it just works (T.M.)