Collect useful data in $dependency property

I was thinking, there should be a way to handle situations where the property isn't directly on the entity like $entity->property but could be nested further down like $entity->something['property'] or even more complex.
There isn't any existing hook I'm aware of that would need this, but for example something like books would require a more complex system.
A potential solution would be to have a parents array, but I wonder if using a callback to set/get the property would be more flexible, something like that could even add value to the taxonomy hook I couldn't deal with earlier.

I've been thinking about it and looking over it, and the callback method seems too convoluted.
I think entity_dependency_add() should be able to handle a parents array, in addition to a simple string property

So if you have $node->property you can do:

entity_dependency_add($dependencies, $node, 'node', 'property');
or
entity_dependency_add($dependencies, $node, 'node', array('property'));

but if you have $node->book['property'] you would have to supply:
entity_dependency_add($dependencies, $node, 'node', array(array('book', 'property')));

Note the nested array. The function would then dig down through those parents, and at each iteration distinguish between array/object syntax (sigh).

I'll come up with the code.

Still can't deal with that taxonomy hook, it's just too weird. Why can't taxonomy entities have a 'full mode' or something where all the relevant data is attached :/
Actually in reverse, when saving a term, it does in fact have a 'parent' property http://api.drupal.org/api/drupal/modules%21taxonomy%21taxonomy.module/fu...
Maybe that could still be handled then as $term->parent['delta'] hmmm~! I'm a little excited

It could be handled like so

<?php
/**
 * Implements hook_entity_dependencies()
 */
function taxonomy_entity_dependencies($entity, $entity_type) {
  if ($entity_type == 'taxonomy_term') {
    $dependencies = array();
    $terms = taxonomy_get_parents($entity->tid);
    $delta = 0;
    foreach ($terms as $tid => $term) {
      $dependencies[] = array(
        'type' => 'taxonomy_term', 
        'id' => $tid,
        'property' => 'parent',
        'delta' => $delta++,
      );
    }
    return $dependencies;
  }
}
?>

you beauty, this data would be very handy to correct an import of a taxonomy term

This is a new patch which includes the changes from the previous patches, and it adds the ability to entity_dependency_add() to handle an array of parents to target a property that is nested down further within the structure of the object. I've removed the check for the anonymous user id 0 because it was redundant with the !empty($value) check.
I am in the process of testing this functionality with a Book implementation at #1589344: Book module?
The taxonomy_entity_dependencies() function is also improved as per #2.
As before, the current usage should not be compromised, only added to.

I've kinda figured out what the limitation is that isn't allowing me to do the Book stuff properly. We're assuming that the property that relates the entity to the dependency is an entity id - and that just might not always be the case. Things can be related through other ways.
Unfortunately in the case of books (or anything that might be related by path/menus) even if we say in the dependency "it's related through mlid" (e.g. $dependency['keys'] = array('mlid'); or something like that) what can really be done by that in a automated reusable way? There is no $node->path['mlid'] or anything like that, it's all custom work. *sigh* I guess it's still worth noting that it's a connection made through mlid in the dependency just so the developer using it can detect that if they want to.
Someone made a module for exporting books, I'm going to study it a little to see if I can get any more insight.

These newly returned keys in the $dependency should be documented in the api file at hook_entity_dependencies().
In addition to the ones noted in these patches I've also devised a 'relationship' array key for a situation where there is a relationship held through something other than an entity id http://drupal.org/node/1589344#comment-6028322
There would ideally be support for another array key for a relationship not held through *any* property, but that requires custom callbacks to get and set the relationship value, but I'm not there yet. By 'support' I don't imply anything huge, just that it would be a documented convention, not anything actually used internally within this module.

I've made it a bit inconsistent by having fields return field_name/language/delta/property and some things return a properties array to drill down to the property. I think fields are a special case so it's ok, but it *could* be changed to give an array for consistency.

Now I'll reveal why these changes are awesome. You can change the property that stores the id like so:

<?php

/**
 *  Set a property according to $dependency for the property location and $new_value
 *  for the new value.
 */
function blah_blah_blah_set_property(&$entity, $dependency, $new_value) {
  if (isset($dependency['field_name'])) {
    // This is a field.
    $entity->{$dependency['field_name']}[$dependency['langcode']]
      [$dependency['delta']][$dependency['property']] = $new_value;
  }
  else {
    // Some other property.
    if (isset($dependency['property'])) {
      $property_path = $dependency['property'];
      if (!is_array($property_path)) {
        $property_path = array($property_path);
      }
      $value = &$entity;
      foreach ($property_path as $p) {
        if (is_object($value) && isset($value->{$p})) {
          $value = &$value->{$p};
        }
        elseif (is_array($value) && isset($value[$p])) {
          $value = &$value[$p];
        }
      }
      $value = $new_value;
    }
  }
}
?>

Why would you want to do that? Because when you move entities to another site, or duplicate them on the current site, or god knows what, the entity ids can change and we can't rely on those anymore. So this is how you would update the dependency to reflect the new entity ids, as long as you have a way to reliably identify an entity other than by it's entity id (e.g. uuid, or through user input) the solution will become apparent. And since you can't rely on dependent entities coming first we can do things with this function like set placeholders until the dependent entity rears it's ugly head, and have a process that fixes things up at that point.