Handle atomicity

[colorfield]

The schema and update hooks have to be converted.

• serial_schema
• serial_field_schema (documentation for D8)
• serial_update_7130, serial_update_7131, serial_update_7132

The module does not create any table on install. It triggers table creation while creating a field on a content type. The table created is then "serial_" suffixed with a md5 generated string 'serial_' . md5("{$entity_type}{$bundle}{$field_name}").
There was already a todo left under D7 about improving this naming convention.

function _serial_get_table_name($entity_type, $bundle, $field_name) {
  // Remember about max length of MySQL tables - 64 symbols.
  // @todo Think about improvement for this.
  return db_escape_table('serial_' . md5("{$entity_type}_{$bundle}_{$field_name}"));
}

The table columns are sid - primary key ("The atomic serial field") and uniqid - unique key ("Unique temporary allocation Id") that relies on http://php.net/manual/en/function.uniqid.php.

[colorfield]

To feed the discussion

• Entity Storage, the Drupal 8 Way
• Storing Data in Drupal 8

We should really avoid custom tables, I will start on a branch that tries to stick to the API. Entity instances uuid (e.g. node.uuid) can replace the serial_*. uniqid, right ?

Feedback really appreciated, especially on this

The allocation of serial numbers by this module is atomic. In other words, the serial values are unique even when multiple instances of the same content type / entity are created simultaneously.

[colorfield]

A first solution that is not atomic a920ab4
We do not rely on the SQL auto increment anymore, this will be implemented via #11