7.x-1.6 and 7.x-1.7 updates do not work with prefixed tables.

Same here

My serial tables are now named

serial_87ba73865a3671ae6575d8a76d4e46dc
and

serial_c67534813a4f58d0b6a606d65e246804

I have had to just revert to the last module and rename the tables back

Hi,

It seems there is a bug in function serial_update_7132():

list(, $entity_type, $bundle, $field_name) = explode('_', $table);

Should be:

list(, $entity_type, $bundle, $field_name) = explode('_', $table, 4);

As $field_name can contain one or more underscores.

Regards,

Martin

Just came to report this same bug, the fix in #6 is correct and needs to be pushed out asap!

This is fixed in 7.x-1.7.

Same problem for me but even with 7.x-1.7 I get a PDOException :

Apr 25 12:24:23 server2 drupal: http://www.example.com|1461601463|php|127.0.0.1|http://example.com/|http://example.com/|0||PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'example_prod.drupal_serial_202a4066a3c3a830434b59431e645e87' doesn't exist: INSERT INTO {serial_202a4066a3c3a830434b59431e645e87} (uniqid) VALUES (:db_insert_placeholder_0); Array#012(#012 [:db_insert_placeholder_0] => 571e44b7077cb9.18631440#012)#012 in _serial_generate_value() (line 164 of /home/example/public_html/sites/all/modules/serial/serial.inc).

Can't figure out how to solve this issue.

My tables doesn't have _node_ which should have been added with the update.

The problem comes from the function _serial_get_table_name which return a MD5. My tables name are not hashed...

Hi,

santeref, did you install 7.x-1.6 then 7.x-1.7?

If it is the case, you must fix the table names manually (that's not great but it's the only way in that particular case).

Given all your serial fields, you must find out what new table names were computed by 7.x-1.6.

E.g.:
- field_client_number on node type client would have generated table name serial_29d8e57bed3226748e11d946558f4176 with 7.x-1.6
- With 7.x-1.7 the (right) table name would be serial_0b1427a67ed3727cf510b0e1ca690ca4

If you have multiple serial fields on the same bundle of the same entity type (on the same node type for instance), only one table should have been renamed by 7.x-1.6, the others should have the right name (if you ran the 7.x-1.7 update).

Hope it helps.

Regards,

Martin

Yes, I do !

But my problem is that my tables were not hashed with 7.x-1.6.

Without success, I have tried to run 7131 and 7132 updates to get the tables renamed and after hashed.

In your example field_client_number stay field_client_number and doesn't become serial_29d8e57bed3226748e11d946558f4176 with 7.x-1.6...

Neither serial_29d8e57bed3226748e11d946558f4176 was generated.

Maybe my issue is not related to the plugin or I am missing something.

The update did not work for me because my tables have a Prefix. If you look at https://api.drupal.org/api/drupal/includes!database!database.inc/function/db_find_tables/7.x which is used in function serial_update_7131() it says -

$table_expression: An SQL expression, for example "simpletest%" (without the quotes). BEWARE: this is not prefixed, the caller should take care of that.

#14 make sense to me too because my table are prefixed !

Thanks @SkidNCrashwell

This patch has worked for me.

Two things:
1) You're using ltrim() to remove the prefix, depending on your prefix this could return "over trimmed" table names, you should do something like substr($table, strlen($prefix)) instead.
2) I presume db_rename_table() re-inserts the prefix itself, if so fine, just thought I'd check.

I always read the release notes before attempting an upgrade, so I found this issue. What I'm not clear on, is to how to successfully make this update. I'm currently using 7.x-1.6 so my table names come from that update which it seems was incorrect.

From comment 12 I deduce that I need to 'fix something manually' after updating to 7.x-1.7, but I checked for a readme and the commit message, and there's no mention of what needs fixing or how to fix it.

If anyone would be kind enough to explain, that would be great! Thanks.

@WorldFallz - did the update actually run and complete? Does it still say you have pending updates when you go to update.php? If it does then you should be OK to apply the patch and run update.

If not, then it the install file may have to be written to re-run the last two updates.

Thanks for the reply skid.

and yep, the update from 1.6 ran. I install with drush so it's done automatically, but I double checked and there are no pending updates.

I can look at the update hooks and perform them manually, but comment #12 says that the tables must be renamed manually, but then doesn't to what.

Might be best to update the system table entry for serial then and run the update again (after applying patch).

db_update('system')
  ->fields(array('schema_version' => 7130,))
  ->condition('name','serial')
  ->condition('type', 'module')
  ->execute();

using drush, you could do a drush php-eval and wrap the above in double quotes.

The above is not tested but I'm sure it will work.

brilliant-- even better. Thanks for the nudge in the right direction.

@WorldFallz - No problem.

I would like to add that the comment in #19 is completely valid and ltrim() shouldn't be used.

Could we get another patch ready?

Thoughts on the best way to handle situations if 7131 and 7132 ran and failed in update hooks?

The easy (lazy) approach might be best to put notes in a README.txt explaining that the system table should be updated as per #23 and then run the update again.

Better might be to create update_7133 and check for any DB tables starting {prefix_}serial_{content_type} and if there are, call updates 7131 and 7132 again. A foreach on node_type_get_types() should work.

I'm happy to create the patch if the latter option is required.

That patch should be fine!

It is true that ltrim could be a problem depending of the prefix.

I agreed that an update_7133 should be created.

New patch using #26 and adding a new update hook to rerun 7131 and 7132 if they failed.

Tried #23, which resulted in the following in the watchdog table:

Notice: Undefined offset: 3 in serial_update_7132() (line 95 of /var/www/html/dev/sites/all/modules/contrib/serial/serial.install).

Funny thing is, update.php reported no errors-- it was only after I still received the PDO exception and checked the log that I saw the update didn't take.

And examining the db showed the table names to be unchanged (serial_). The fact that the tables are not being renamed is what's causing the undefined offset, but I've no clue why update 7131 isn't happening. Can I just run that code directly?

My table names are not prefixed.

What are the names of your Serial tables in your database? I'm guessing that as you had the error on line 95 you haven't applied the patch?

Something must have run, maybe it was caching issue or something. At fist the tables were unchanged now they are:

serial_node_node_1b11e2f0bdec5751027614502bdb5bb0
serial_node_node_2da2869965b37221211b9a4f8ee3bde9
serial_node_node_48b84ac89c60e136657dd820efcd93b6
serial_node_node_fbe81a57e0e3912d84bd219886de655f

I was going to try to run the latest patch, but I'm afraid that would only make things worse. I'll probably have to create a custom update function to fix them, but at this point I'm not even sure what they SHOULD be. Any suggestions are welcome!

Guys, please remove the Release 1.6 and 1.7 because it does not work.

Version 1.7 seems to be working perfectly for me. I couldn't get the updates to take though-- likely because of my manual efforts to fix the tables before updating.

In the end I simply deleted the serial fields, recreated them, and resaved the affected nodes. Luckily the site was still in development and there weren't a lot of cross references using serial IDs yet, so I only had to manually fix a few references after recreating the fields. On a prod site with heavy usage of the module and some deleted nodes with serial ids, it would have been a disaster. :-(

#23 and #29 did not work for me. This update breaks things :/

#12 work for me.

Patch in #29 works when you update the module, patch it, then release it + run an update-db.

Tried the latest version (1.8) with patch 29 and no go.

@Ashzade - This thread and patch is for versions 1.6 and 1.7. If you bypassed these versions then it is very unlikely to work.

@DrupalGideon: Of course, don't know how I missed that.

I updated to 1.8 -> no tables converted in the db but serial searches for the new tables so the site broke.

I tried patch in #29
set the serial module status to 7000 (to force the update to be reapplied)

I got the following result
serial module

Update #7130
Failed: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'r.d7_serial_be14b1b5a8adf32d04beaeacef1eb9f8' doesn't exist: DELETE FROM {serial_be14b1b5a8adf32d04beaeacef1eb9f8} ; Array ( ) in serial_update_7130() (line 61 of /var/www/r/public_html/sites/all/modules/serial/serial.install).

the serial tables are not converted to the new naming format.

I dit the following:

drush dl serial-7.x-1.7
wget https://www.drupal.org/files/issues/7_x_1_6_and_7_x_1_7-2710301-29.patch
patch -p1 --verbose --dry-run <7_x_1_6_and_7_x_1_7-2710301-29.patch
patch -p1 --verbose -<7_x_1_6_and_7_x_1_7-2710301-29.patch
drush updb
--> first upd db timed out, we have +- 15 serial fields and large tables

serial_hash tables are created
previous serial_field tables are still present

update.php -> update hook 7133 kicks in.

Now we have +- 30 serial_hash tables so double of the number of serial fields.

When trying to add a node, there is no serial value added to the node, and in our case it is a mandatory field.
So we are back on v1.5

Same issue here. I tried to update from v1.5 to v1.8 without success. The site was broken.

I had to go back to v1.5

So there is currently no fix?

I've just tried some method to get this module updated, no luck

Originally I was using serial 7.x-1.4, site running !, great !

Updated to 7.x-1.5, still run

Update to 7.x-1.6 ... crash ... sad

Update to 7.x-1.7 ... still crash ... depressed ... :)

I used drush, received this message

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dr_va.dr_serial_eeb6eba95f74b33a763cd6e5cb8f1d83' doesn't exist [error]

It seems remaining steeps (7131,7132) wasn't performed

so, what is the right method to upgrade this module to 7.x-1.8 ?

Thanks

@Gusantor,

The patch in #29 is what I successfully used to upgrade to version 1.7. It will run those hook_updates 7131 and 7132 for you. After you have got those running you can update to 1.8.

thanks @DrupalGideon

I applied that patch over current version 1.7

It fail with same message table doesn't found

I now reread you post and see you went from 1.6 to 1.7, and so, applied patch over 1.6 ?, is that ?

I'll try that soon

thanks

Hello, so I did some tests, no good news

I just installed Drupal 7.59

Installed serial module 7.x-1.4 (through admin/modules/install)

Added serial field to Article content type

Create some dummy content with Devel generate, everything ok, two tables in DB (no prefix) :

`dr_serial_test`.`field_data_field_serial`,
`dr_serial_test`.`serial_article_field_serial`

run drush dl serial --select, upgrade to 7.x-1.5
run drush updb, no db update

again

run drush dl serial --select, upgrade to 7.x-1.6
run drush updb, updates 7131, 7132 appears, performed ok

db tables:

`dr_serial_test`.`field_data_field_serial` remains
`dr_serial_test`.`serial_article_field_serial` changed name to `dr_serial_test`.`serial_4685c406034213ba77966a04aa3de97a` (<--here)

again

run drush dl serial --select, upgrade to 7.x-1.7
run drush updb, no db update
patch < 7_x_1_6_and_7_x_1_7-2710301-29.patch, apply patch #29, ok
run drush updb, update 7133 appears, preformed ok

try to create an Article, and error

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dr_serial_test.serial_1de57c6c66df5a99f9670f006c8c533f' doesn't exist: INSERT INTO {serial_1de57c6c66df5a99f9670f006c8c533f} (uniqid) VALUES (:db_insert_placeholder_0); Array ( [:db_insert_placeholder_0] => 5b1b1b50db3c21.92939344 ) in _serial_generate_value() (line 164 of /home/mauricio/drupal/serialTest/sites/all/modules/serial/serial.inc).

interesting part is that serial_1de57c6c66df5a99f9670f006c8c533f doesn't match serial_4685c406034213ba77966a04aa3de97a

Because

1de57c6c66df5a99f9670f006c8c533f is MD5 for node_article_field_serial

and

4685c406034213ba77966a04aa3de97a is MD5 for ???

well, today is friday and I guess tomorrow will be a long day ... :)