If there are node reference and user reference fields, we should also have one for UUIDs. It should be a clickable link to the entity in question, whether this resolves to /node/something, /user/something, etc.. It could simply be a text field with 36 characters with some added bits like the other reference fields.

It would require a uuid_get_path_by_uuid() function, which will hopefully come out of #1181982: Add menu hook for linking to UUIDs.

#12 entityreference_uuid.zip4.53 KBolofjohansson
Members fund testing for the Drupal project. Drupal Association Learn more


skwashd’s picture

I think that this feature belongs in the references module. They should depend on UUID and use UUID for the references. This would make exporting content a lot easier too.

skwashd’s picture

Project: Universally Unique IDentifier » References

Reassigning to the References module issue queue. Apologies in advance if the reassignment isn't appreciated, but I think the feature belongs in that module. I'm happy to assist in making this happen as time permits.

colan’s picture

Makes sense to me. I had a hard time deciding which issue cue to post this in. ;)

yched’s picture

IIRC, the" UUID in core D8" approach currently takes the approach that nids are still used for internal db foreign keys. If that's so, noderef / userref fields will keep storing nids / uids, not UUIDS, as raw values.

Side resolution of UUIDS could happen at field load, either by some if (module_exists('uuid')){ code in node_reference_field_load(), or through a hook_entity_load() in uuid.module.

I guess this would need a clearer definition od the expected features :-)

colan’s picture

Project: References » Entity reference

Anyone have any objections to moving this to Entity Reference?

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

Hi there!

This module references the internal ID of the target entity. That's by design and it's not going to change. Mapping to and/or from an UUID is not in the scope of this module. This is usually done during import/export (in modules such as Migrate), and is not generally useful inside a given site.

colan’s picture

Project: Entity reference » References
Status: Closed (won't fix) » Active

Moving back to References then.

yched’s picture

Project: References » Entity reference
Status: Active » Closed (won't fix)

"Entity Reference" will most probably take over the "References" project shortly. So if this is a "won't fix" for "Entity References", it will probably stay that way.

Besides, the maintainers of both modules have basically said (#4 and #6 above) that they didn't see the point, for the same reason (local ids will still be used internally) - so you probably want to further explain your use case if you want the feature to move forward.

colan’s picture

Status: Closed (won't fix) » Active

Right, good idea. For the Syndeploy module I've been working on, it's necessary to maintain a log of changes on a Drupal site so that these can be propagated elsewhere. Each log entry is an instance of a content type that has a UUID field to refer to the entity that has been created, updated or deleted. UUIDs are necessary so that the receiver sites will be acting on the correct items when using the feed to update their own content.

Currently, this UUID field is implemented as a simple text field. This works find for machine-to-machine communication, but administrators should be able to look at a human-readable display of the view of log entries, and navigate to each changed entity from the log. As a text field though, there aren't any click-able links to get there; the UUID field would need to be a reference to the item in question. So it should be possible to have a UUID reference field so that it will automatically link to the item with the entered UUID.

Would this functionality be best in one of the reference modules, the UUID module or its own module?

yched’s picture

Sounds like outputting UUIDs belongs to a custom formatter ?
As explained above, the general approach regarding UUIDs is that they will not be used as foreign keys internally, and resolution between local ids and UUIDs happens at runtime. Reference fields will not go against that core practice.

olofjohansson’s picture

I'd like to see this as well.

My use case is the following:
I have two sites, site A and site B. Site A will store all the content (terms, nodes etc.) and Site B will import that content and display it in a regular way. The nodes on Site A have several references from node -> nodes, node -> terms and so on. However, I might want to store the terms from Site A as nodes in Site B, which means that the nids won't match the nids in Site B.

Every entity in Site A has a UUID, and that UUID is exposed as the referenced entity when I'm importing the content. And because I'm importing a lot of content at the same time, I can't be certain that the referenced entity has been imported yet. This means that I can't look up a nid using the UUID, to create the reference.

A bit hard to explain, but I hope you'll understand my needs.

olofjohansson’s picture

4.53 KB

I've created a small module that adds a behavior to the existing field types. This behavior will simply store the reference by UUID instead of entity ID in the database.

This is done in three steps:

  • Alter the field definition for the schema
  • Change any entity ID into the UUID before saving the value, using presave
  • Change any UUID into to entity ID when the value is loaded from the database

There is one problem, and that occurs if the user disables the behavior after the field has been populated with some data. I don't know if it's possible to prevent this, since I don't know that much about behaviors.

I don't know if this is the best approach, but it did solve my needs. I haven't created a real project, but if this seems like a good approach, we could consider what to do next.

colan’s picture

Status: Active » Needs work

Simply adding a new formatter for this makes sense to me. Doesn't the approach above (#12) break "resolution between local ids and UUIDs happens at runtime"?

sea4’s picture


Thanks for the discussion. My 2 cents is that there should be support for uuid. I have a situation where I tried migrating content from site A -> Site B using the deploy module. The referenced and referencing nodes throw errors, including database ones (from the logs).

So i believe, since this module is becoming more important in relating entities together,( for world peace to happen,) there should be a choice to use the default ids (for "simpler scenarios") or uuid if the module is install. (maybe a sub-module or a related project)

My experience with this module has been great! keep up the excellent work!

jpstrikesback’s picture

@ojohansson - this is interesting stuff, would you be up for sticking it in a sandbox?

minorOffense’s picture

I would say instead that the option to use the UUID value or Entity ID value should be set at the field settings level. Meaning once it's set you can't switch back and forth between them. Simplifies the workflow and there's no data conversion happening.

thedavidmeister’s picture

I agree with #16. Unless there's a strong use-case for leaving UUID/ID open ended we should lock it down when the field is created.

Knowing that your reference will be a UUID or ID during entity_load() rather than entity_view() is most likely what developers are really looking for when they say they want "support for UUID references".

colan’s picture

Issue summary: View changes

Made the link to the other issue a proper issue link.

bendiy’s picture

I'll add another use case...

I have remote entities exposed to Drupal. These entities load over a REST API and do not have serial ids, but use UUIDs. I would like to make references from basic local Drupal entities to these remote entities. e.g. Drupal Commerce Order referencing a remote entity Contact via UUID.

damiankloip’s picture