2

I have created a custom entity with several properties and several attached fields.

When I load a instance of my custom entity, update a property of the entity (e.g UID) and save it a new revision of the entity is created, but also a new revision of every attached field is created.

To avoid saving lots of redundant data I only really want to create a new revision of an attached field if the data in that field has changed.

I've noticed that this same behavior is exhibited by core node objects, but is still not really desirable.

My function which currently saves my entity looks like this:

/**
* Saves a emtr safe check to the database.
*
* @param $emtr_safe_check
*   The emtr_safe_check object.
*/
function emtr_safe_check_save(EMTRSafeCheck $emtr_safe_check) {

    $is_new = isset($emtr_safe_check->is_new) ? $emtr_safe_check->is_new : false;

    // always make a new revision
    $emtr_safe_check->is_new_revision = TRUE;
    $emtr_safe_check->save();

    if($is_new) {
        // now we have the new emtr safe check id lets save the attached fields
        field_attach_insert('emtr_safe_check', $emtr_safe_check);
    } else {
        // This is where my attached fields are saved
        // Can I do something clever here to avoid creating redundant revisions?
        field_attach_update('emtr_safe_check', $emtr_safe_check);
    }

    return $emtr_safe_check;
}
5
  • 3
    There was an issue for this in D7 queue: Deeply decouple revisions from Entity API and Node module. But it was change to D8 and the discussion has moved on to a new issue in D8: Reconsider the separate field revision data tables. So, I think the simple answer to your question is "no". David Rothstein suggests that it might be possible to rewrite the field_sql_storage module as contrib that does this differently, but I'm pretty sure there hasn't been any meaningful work done to that end. Mar 5, 2014 at 20:53
  • 1
    Interesting reading. I noticed by the end of the first thread the issue had been moved to the D9 queue - that really is a no! Looks like the options are stick with it how it is or re-write field_sql_storage.
    – Felix Eve
    Mar 6, 2014 at 8:59
  • I don't think you can. An alternative would be not to use fields with your entity. (Does not help much!!?)
    – awm
    Mar 9, 2014 at 19:42
  • I just remembered coming across this issue (Beans need revisions) when writing a small helper module that hides the bean revision field. That seemed to indicate that beans have the ability to be saved without creating a revision (as it was the original default). I just ran a few tests and can confirm that if you uncheck the "Create new revision" checkbox, no revision rows are added to the DB. I haven't done any further investigation, but for now, it seems my answer has changed to "Yes, it seems to be possible". Mar 10, 2014 at 15:29
  • I posted an answer below, does anyone think this could work or it's a bad idea?
    – awm
    Mar 28, 2014 at 0:36

1 Answer 1

1

I have looked around and found one HACKY solution. I think it probably has some serious side effects that you may be able to handle with custom code and db queries. This is definitely not a generic solution.
I did my test on the node entity and every thing worked fine in my 5 min test case. Here is what I did:

function playground_node_presave($node){
  dpm($node);
  // do a query here and check if the value is in the field_revision_table is
  // equal to the value on the node/entity object.
  unset($node->field_cookies);
  dpm($node);
  // The node will be saved without changing the value of the field and without creating 
  // creating a new entry in the field_revision_table.
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.