Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#12 | entityreference_uuid.zip | 4.53 KB | olofbokedal |
Comments
Comment #1
skwashd CreditAttribution: skwashd commentedI 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.
Comment #2
skwashd CreditAttribution: skwashd commentedReassigning 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.
Comment #3
colanMakes sense to me. I had a hard time deciding which issue cue to post this in. ;)
Comment #4
yched CreditAttribution: yched commentedIIRC, 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 :-)
Comment #5
colanAnyone have any objections to moving this to Entity Reference?
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedHi 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.
Comment #7
colanMoving back to References then.
Comment #8
yched CreditAttribution: yched commented"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.
Comment #9
colanRight, 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?
Comment #10
yched CreditAttribution: yched commentedSounds 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.
Comment #11
olofbokedal CreditAttribution: olofbokedal commentedI'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.
Comment #12
olofbokedal CreditAttribution: olofbokedal commentedI'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:
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.
Comment #13
colanSimply 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"?
Comment #14
sea4 CreditAttribution: sea4 commentedHi,
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!
Comment #15
jpstrikesback CreditAttribution: jpstrikesback commented@ojohansson - this is interesting stuff, would you be up for sticking it in a sandbox?
Comment #16
minorOffense CreditAttribution: minorOffense commentedI 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.
Comment #17
thedavidmeister CreditAttribution: thedavidmeister commentedI 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".
Comment #17.0
colanMade the link to the other issue a proper issue link.
Comment #18
bendiy CreditAttribution: bendiy commentedI'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.
Comment #19
damiankloip CreditAttribution: damiankloip at Tag1 Consulting commentedThere is also https://www.drupal.org/project/uuidreference