Reference UUID Synchronization

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
BenVercammen's picture

I've written a module that maintains relationships between a node and all of its "reference fields" across multiple Drupal instances, based upon the UUID of the referenced entities. The "Node export relation" module didn't quite cut it for me (even after modifying it), and I never found anything else that seemed to fit the bill.

I'd like to share this via a Drupal project, but first wanted to check if the module is actually useful, and whether it doesn't overlap with another one (didn't really find one that truly covers the same topic).

The module roughly works like this:

  • for each "reference field table" (ie: "field_data_field_..." and "field_revision_field_...") an extra "reference UUID" column is added next to the "reference ID" column
  • when creating or updating a reference,
    • we check the "reference field value array" (see below for what I mean by that)
      • if a UUID is available, we don't trust the NID/TID and either resolve it via the UUID or set it to NULL to resolve it later on
      • if no UUID is available, we assume we can trust the NID/TID to be correct and resolve the UUID via the NID/TID
    • we run over all other "reference field tables" and try to resolve any existing NULL references given the current UUID and NID/TID
  • when exporting nodes we make sure the UUID of each reference field is added to the export

The hooks we use are:

  • hook_node_insert()
  • hook_node_update()
  • hook_taxonomy_term_insert()
  • hook_taxonomy_term_update()
  • hook_node_export_node_alter()

The "reference field value array" I'm talking about looks like:

$entity->field_some_node_reference['und'][0]['nid'] = '12';
$entity->field_some_node_reference['und'][0]['uuid'] = '7f993511-b842-48dc-b8aa-3c261c397422';

In the end, when this module is enabled, I can import nodes and restore all references

  • when performing a clean install via a "node_export feature" included in the install profile
  • when importing via the Feeds module (requirement is that the UUID value for each reference is passed in the XML and parsed/processed correctly)

The only issue I currently have with my solution, is that during "insert" and "update" the performance may be influenced by this module. However, my current project isn't too "CRUD intensive", and viewing nodes doesn't get influenced, so it's really not that big a deal.

Now, for my actual question: does this module make sense, or is it something that's already been covered by something else? Or am I missing something (obvious)?

I'd be happy to share my code, but first wanted to make sure it's really worth it...

Comments

for each "reference field

Garrett Albright's picture

for each "reference field table" (ie: "field_data_field_..." and "field_revision_field_...") an extra "reference UUID" column is added next to the "reference ID" column

I strongly suggest you consider implementing this without mucking about with other modules' tables. That's a no-no.

Initially I was planning on

BenVercammen's picture

Initially I was planning on not touching any existing tables, but ...

  • I already had to update a lot of the values inside those tables (okay, not the same as modifying the table structure, but still...)
  • it was very useful to have both values next to each other in the same table (for debugging)
  • I wrote it as an "add-on" to the "references" (and thus the "fields") module, so it didn't seem all that harmful to modify those tables
  • when looking only at the DB structure (not keeping any other architectures in mind), it just felt like the right place to put the extra information
  • and what really did it for me; the UUID module also adds columns instead of working with an extra lookup table (eg: the node table)

The counter-arguments that I could think of were

  • it isn't clean to modify other modules' tables (though I didn't know it's an actual "no-no")
  • I already experienced how UUID sometimes messes things up (http://drupal.org/node/1281132)
  • ... (maybe I'm not doing my best right now)

So I have considered to "play nice", but for me there were more "pro" than "con" arguments in this case. Either way, if you have any additional arguments I'm always open to reconsider the implementation.

You can find the sandbox project on http://drupal.org/sandbox/BenVercammen/1398752.

Contributed Module Ideas

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week