The Schema API has 'serialize' option which is great but Database API does not work with this information at all. The only issue-free operation is working with entities. But that is Entity API's doing and not Database API. Since D7 brought the new DB layer it should handle this automatically.

Personally I have tremendous problems with serialized data in custom Fields when loading and/or saving.
I don't think that implementing a Schema checking of table settings for particular table into the Database layer should be that much of a problem or performance issue.

Comments

Anonymous’s picture

Version: 7.x-dev » 8.x-dev
Category: task » feature
Priority: Major » Normal

This isn't a task but a feature request for something not yet implemented. Feature requests belong in 8.x-dev. I don't know the validity of the request.

Anonymous’s picture

This is still not implemented in D8. I thought that this code will do the trick but obviously drupal_write_record() is not used to execute queries(:))
schema.inc #427 - #433

    // Build array of fields to update or insert.
    if (empty($info['serialize'])) {
      $fields[$field] = $object->$field;
    }
    else {
      $fields[$field] = serialize($object->$field);
    }

I created a table with one serialized column(blob) and used simple insert query:

db_insert('mytable')->fields(array('myfield' => array('test')))->execute();

and I retrieved the data with:

db_select('mytable', 'm')->fields('m', array('myfield'))->execute()->fetchAll();

which returned a STRING 'test'. So I tried to insert array with more than one value(array('test', 'something', 'else')) which returned an error:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[21S01]: Insert value list does not match column list:...

I also tried to insert serialized string and query returned it correctly - unserialized. So from my understanding there is still no 'serialized' support implemented.

I understand that this cannot work with db_query() but In my opinion this is a must when using db_select().

Anonymous’s picture

Priority: Normal » Major
Issue summary: View changes

I'm bumping into this issue again in D8(Alpha 7). From my perosnal experience this is can be a tremendous PIA so I'm changing the priority. Maybe someone won't agree but again, I see this too often to ignore.

Anonymous’s picture

For example, I have a content entity which has serialized field. In order to be able to work with it properly I have to use this code:

  /**
   * {@inheritdoc}
   */
  public static function postLoad(EntityStorageControllerInterface $storage_controller, array &$entities) {
    // META is serialized and needs special handling
    foreach ($entities AS $entity) {
      $meta = $entity->getMeta();
      // META can be NULL so always set the type to array
      $entity->setMeta((array) maybe_unserialize($meta));
    }
  }
 
  /**
   * {@inheritdoc}
   */
  public function preSave(EntityStorageControllerInterface $storage_controller) {
    // META is serialized and needs special handling
    $meta = $this->getMeta();
    $this->setMeta(empty($meta) ? NULL : serialize($meta));
  }
 
  /**
   * {@inheritdoc}
   */
  public function getMeta() {
    $meta = $this->get('meta')->getValue();
    $value = reset($meta);
    return isset($value['value']) ? $value['value'] : $value;
  }
 
  /**
   * {@inheritdoc}
   */
  public function setMeta(array $values) {
    $this->set('meta', array('value' => $values));
    return $this;
  }
Crell’s picture

IMO, the serialize flag in schema API should be removed. It has nothing to do with databases and is an application-level question. It was only added, I think, for drupal_write_record(), which we are trying to remove anyway: #1774104: Replace all trivial drupal_write_record() calls with db_merge()

jhedstrom’s picture

re: #5 can this be re-classified as a task and completed in 8.0.x, or is this 8.1.x, or even 9.0.x material?

jhedstrom’s picture

And by 'this', I mean changing this issue to be about the removal of the serialize flag.

Crell’s picture

Title: Database API needs to check if column is serialized » Remove serialized column data from Schema API

drupal_write_record() is gone now, isn't it?

We should remove the serialize flag, but I fear that won't pass beta evaluation. It's an API change, even if it's removing an API that isn't being used. I suspect we'll have to retitle this issue but target it at Drupal 9 at this point. :-(

jhedstrom’s picture

Category: Feature request » Task

Moving to task.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

jcisio’s picture

Version: 8.9.x-dev » 10.0.x-dev

I guess it can only be removed in the next major release.

Version: 10.0.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.