Using the most recent dev release, I noticed something strange - when loading the entity (i.e. hook_entity_load() and controller::load()), the field data is nested like:
$entity->field_name['und'][0]['tablefield']['tablefield']
But when saving the field data is nested like:
$entity->field_name['und'][0]['tablefield']['tabledata']

Now, since I am doing a bit of hacking on it, I will certainly concede it may be down to my hacks -- but I am certainly not intentionally attempting to do this. But, can someone confirm this? If this IS happening, is this just some structural quirk or workaround to be compatible with the field API? Thanks. See images below for code and dpm() output inserted in my custom module for hook_entity_load() and hook_entity_update().


function custom_entity_update($entities, $type) {
    dpm($entity, 'on save()');
}

function custom_entity_load($entities, $type) {
    foreach ($entities as $entity) {
      dpm($entity, 'on load()');
    }
}

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

robertwb created an issue. See original summary.

lolandese’s picture

If I recall well the first index key 'tabledata' is remained unaltered in the code, thus is there as legacy.

When introducing a better database storage of the field in #2697105: RFC: Proposal to Enable Table Data Storage as JSON it resulted in the second structure (as indicated in your last image). This was necessary because the actual table data (cell values) had to be separated from the caption and other "metadata".

I guess a refactoring to make the index keys be consistent wouldn't hurt. A patch would be welcome.

robertwb’s picture

OK thanks for the sanity check -- I just wanted to make sure that it was indeed a remnant. I will look at developing a patch, though I was having difficulty determining where in the code this nesting was taking place.