Replicate/UUID compatibility

Thanks for spotting/fixing this issue! Live saver =) Just rerolled the patch to allow it to support abitrary uuid/vuuid keys as per other code.

I think this patch belongs in the replicate module as UUID tries to avoid hanging contrib use cases. You could make uuid a soft dependency by wrapping the unsets in if (module_exists('uuid')).

Updating title after move.

Here's that same patch ported to the replicate module (seems to have also fixed the file modes to not be executable).

sounds like you'll be in a coming / going issue here as replicate also doesn't want to specifically account for contrib ;)

Can we put a sub module in place for uuid? replicate_uuid or something?

Though arguably speaking uuid could be considered a special case. You never want to duplicate that value.

not maintainer but +1 for accepting since any kind uuid exists it is effectively an additional primary key and personally wish it was in core since it's something I activate on almost every site ever. no negative effects of handling it any other way and I think a lot of replicate-contrib modules / add-ons would provide this same thing since as the #8 suggests, it is supposed to be unique everywhere in existence.

Those file mode changes are unnecessary.

I'll admit the file mode changes don't belong in this patch.

But those files shouldn't be executable. 755 is the wrong file mode for a .module file.

@minorOffense: You may want to update your checkout. File modes were fixed on 2015-03-13.

This has been a long time since this patch/feature has been posted and I think it should be added to replicate as it is not making assumption that developers want to unset this uuid field to make a replication. In addition, it is not really adding complexity to the module.

However, I would prefer to have it in the replicate_clone_entity() function instead of hook_replicate_entity_alter(). I see the alter() call as a chance to edit the cloned entity, not to reset key fields (at least for fields which are supported by the API module).

See attached patch.

Rebasing patch on the latest dev branch commits.

Also no need to check for uuid module to be enabled,
if (!empty($info['entity keys']['revision uuid'])) {
will do the job.

Whoops, here's the new patch.

I am wondering if https://www.drupal.org/node/2536714 will not fix it automatically if uuid fields are listed under entity keys. I will try to check it.

jgalletta, Your patch in #16 isn't working for me as it's not handling uuid. It's only handling revision uuid

Patch in #14 works for me. version = "7.x-1.1"

While #14 works. Are we sure it belongs in this module (replicate is doing what it's suppose to do.... copy things.)? Are we sure it doesn't belong in uuid module? Are we certain that it shouldn't be a submodule?

Since I don't want to wait and see where the maintainers feel the right place is for this I just did a hook alter with this code and all works.

function mymodule_replicate_entity_alter(&$clone, &$entity_type, &$entity) {
  // If uuid module is used, clear uuid fields so a new uuid is generated.
  if (module_exists('uuid')) {
    $info = entity_get_info($entity_type);
    if (isset($info['uuid']) && $info['uuid'] == TRUE && !empty($info['entity keys']['uuid'])) {
      unset($clone->{$info['entity keys']['uuid']});

      if (!empty($info['entity keys']['revision uuid'])) {
        unset($clone->{$info['entity keys']['revision uuid']});
      }
    }
  }
}

responsibility for inclusion can be debated all day. UUID is core in D8 though while replicate is not so might be nice to do it in replicate D8 and backport to D7 so there's functionality consistency going forward. There is 0 reason you'd ever want an identical copy of a UUID because it breaks the database model / point of having UUIDs!

@20 totally agree with you, UUID's must be unique. Where the logic is placed for #14, feels.... out of place. I only bring this up because it makes more sense to me that D7's version of UUID would do a hook_replcate_entity_alter. In D8 I would be surprised if you can replicate a UUID due to its nature. But then again I have not tested it. Was just bringing up for discussion. In the end it is up to the maintainer.

+1 to RTBC if that is what this maintainer wants.
+1 to patch D7 UUID if both maintainers feel that is better way.
-1 to contrib as @btopro is correct.

What's the timeframe for fixing this? I rely on UUIDs to synchronize my systems. Replicated UUIDs cause issues with that synchronization.

Updated path attached, combined with latest commit from #2536714: PDOException: SQLSTATE[23505]: Unique violation: 7 ERROR: duplicate key value violates unique constraint.

It seems replicate support will never be implemented in the uuid module, as the maintainer doesn't want to support other contrib module outside of the top 100: https://www.drupal.org/project/uuid_extras

"Modules which aren't in the top 100 project list will not be added to this project. Such modules should add UUID support in the core module or via a sub module."

So while I agree with dobe, I think we have to manage uuids in replicate.