Data column isn't serialized

I was trying to do something similar, and getting field exceptions on save. This patch works for me. Marking needs review.

We should use a different name between the serialized version and the unserialized: for example, name the serialized version data_serialized, and keep data for the unserialized (we will have to update the columns in an update function, but that's ok).

The problem is that by changing data like this, we quickly end up in situations where the data is serialized while it shouldn't or isn't while it should (for example when you save the same entity twice). There is no good way around it.

I suggest we do that. Would it work for everyone?

I think I get this. We need to handle the data serialization differently that it is handled in Entity API, for example, since we don't have __sleep()/__wakeup() magic methods or other class helpers to let us know if the data is currently serialized or not? Or is it because people might already have strings stored in there?

The problem is that we don't control the workflow of the field, so we might get stuff that we don't expect: an entity can be saved twice, for example.

This patch seems to work nicely, however under some conditions the update will not work correctly.

Cannot change the definition of field <em class="placeholder">field_data_commerce_customer_address</em>.<em                   [error]
class="placeholder">commerce_customer_address_data</em>: field doesn't exist.

Unfortunately, I am not using the dev version right now, so I can't reroll this patch, but I have attached a patch that will fix this if you encounter it.

@Damien, great to see a good patch in this direction.

In your example of an entity being saved twice, can you please explain in more detail the problem there?

It seems to me, if the data field is unserialized on field load and serialized on field presave then the data column itself could be used for storing the serialized data?

Looking forward to a solution to this.

cheers,

David

Gentlemen,

Any chances on this to be expanded into a general case and committed into core? I am not sure whether it still can be committed into D7? and I am not familiar with D8 and how its core works.

I think since in Schema API it is stated that 'serialize' property means data being serialized and stored as a serialized string, it should be respected including by Field API. Damien's approach on defining an extra property for keeping unserialized information in the original property, while maintaining a serialized copy in another property seems a very good idea to me.

I've been working on a custom field type and I ended up needing this kind of feature for one of the columns of my custom field type. I was searching on the web and google brought me to this issue queue. Though I understand it's been a year since last comment.

And Damien's approach worked for my column. I am pretty confident it can be expanded into a general case, based on whether 'serialize' is set to TRUE in the schema of a field type.

P.S. I could volunteer myself for this general case patch... would be my 1st patch into core.

Rerolled patch coming.

This patch incorporates all of the previous patches (initial, #4, #7), rerolled against the latest release.
Additionally it adds an update hook to serialize any unserialized stored data.

Unless I'm missing something the data isn't namespaced in any way, currently, meaning that plugins could easily overwrite each other's data. This should probably be covered in a separate issue, though.

@bucefal91: Core only respects a schema's "serialize" definition in drupal_write_record(). I'm not sure there's a way to fix this in core without breaking existing implementations.

Updating status.

The last patch is working like a charm and I have nothing to say regarding some improvements we may add to it... I update this issue to RTBC.

Hello,

I use addressfield with Drupal Commerce for my customer profiles.
My shipping profiles have data serialized for phone numbers.
My billing profiles have only basic address information and don't have data serialized.

With this patch (https://www.drupal.org/files/issues/1272168-12-data-field.patch), I have the following warning :
Notice : Undefined index: data dans addressfield_field_presave() (ligne 449 dans /var/www/sites/all/modules/contrib/addressfield/addressfield.module).

I also tried on simplytest.me and I had the same warning.

I modified the patch to fix this warning.

Needed a reroll.

drush updatedb
Addressfield 7002 Serialize existing values in the data_serialized column.
Addressfield 7003 Rename the data column.
Do you wish to run all pending updates? (y/n): y
SQLSTATE[42S22]: Column not found: 1054 Unknown column 't.commerce_customer_address_data_serialized' in 'field list' [error]
Performed update: addressfield_update_7002

I cannot update addressfield

#16 worked - https://www.drupal.org/node/1272168#comment-9224151
I did have to renumber the updates but it did work

@SocialNicheGuru then please set the status back.

In the latest release, it looks like the data column is serialized

; Information added by Drupal.org packaging script on 2015-12-30
version = "7.x-1.2+8-dev"
core = "7.x"
project = "addressfield"
datestamp = "1451474640"

in the addressfield.install

 'data' => array(
      'description' => 'Additional data for this address.',
      'type' => 'text',
      'size' => 'big',
      'not null' => FALSE,
      'serialize' => TRUE,
    ),

In the latest release, it looks like the data column is serialized

@SocialNicheGuru That has been in there since forever, but has no effect outside of drupal_write_record().

@bojanz Why has this been marked as outdated? As far as I can tell there is still not a single serialize() call in addressfield (outside of addressfield.migrate.inc).

Patch now redeclares addressfield_field_load(). Function was added in #2169863: Fix duplicate saving of customer profiles.

Had to move some things around to incorporate the recent changes. No changes to the update hook though.

The updates only run for me if they are in the opposite order. Patch attached for review.