Instead of using an entity's primary ID, entity references should use the entity's UUID.
But the change is so huge for Drupal8,
So we can add a choice to use UUID in entity reference values instead of the entity's ID when create a new entity reference field.

It mill make help for

  1. remote entity reference
  2. migrations, e.g. #2748609: [meta] Preserving auto-increment IDs on migration is fragile.

    3. ...

CommentFileSizeAuthor
#14 2874548-14.patch8.16 KBlawxen
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
CreditAttribution: phenaproxima at Acquia commented

+1 for this!

I am in favor of swapping the roles of serial IDs and UUIDs. UUIDs should be the canonical IDs, and serial IDs should be more disposable, site-specific identifiers. This might require a hopefully-not-too complex migration path, but I think it'd be worth it. And this would be a good first step.

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

This seems like an all around good thing. If we're going to link back to a thing, it's best to use the id that is guaranteed to always be the unique identifier for that thing.

But, in this issue's description, I was hoping to read some kind of insight as to why this is a good and important change. Seeing how doing this would fundamentally change how referenced entities have behaved for a long time.

Can you please fill out the description with an explanation as to why this change is needed and the primary and secondary impacts of this change?

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
CreditAttribution: phenaproxima at Acquia commented
Issue tags: +Needs issue summary update
skwashd’s picture

skwashd CreditAttribution: skwashd at Dave Hall Consulting for Pfizer, Inc. commented

During the 8.0 development cycle there was a proposal to replace serial IDs with UUIDs in urls and other places. On that issue (#1726734: Replace serial entity IDs with UUIDs in URLs, or even globally?) there was some discussion around performance. I would encourage you to review that issue,

For the record, I would love to see UUIDs everywhere.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented
Related issues: +#1726734: Replace serial entity IDs with UUIDs in URLs, or even globally?
skwashd’s picture

skwashd CreditAttribution: skwashd at Dave Hall Consulting for Pfizer, Inc. commented
DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented
Related issues: +#2353611: Make it possible to link to an entity by UUID

I'd love to see UUIDs usable everywhere, but serial IDs for user-visible paths, e.g. node/123 instead of node/4bd1c937-f530-456f-a218-241d7bfd40b8 (though both could be useful). The point of this issue is that entity reference data is internal, it shouldn't be exposed publicly, so it could IMHO be changed to a UUID structure.

heddn’s picture

heddn
Primary language English
Location Nicaragua
CreditAttribution: heddn at MTech, LLC commented

Deleted duplicate comment.

heddn’s picture

heddn
Primary language English
Location Nicaragua
CreditAttribution: heddn at MTech, LLC commented

Deleted duplicate comment.

heddn’s picture

heddn
Primary language English
Location Nicaragua
CreditAttribution: heddn at MTech, LLC commented
Issue summary: View changes

+1
Using uuid for all the things would be wonderful. Baby steps.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented
Issue summary: View changes
Related issues: +#2748609: [meta] Preserving auto-increment IDs on migration is fragile

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

lawxen’s picture

lawxen CreditAttribution: lawxen at Sparkpad commented
FileSize
2874548-14.patch8.16 KB

Functional done.

Still needs:

  1. optimize code.
    Such as:Change name: target_id to target_uuid.
  2. Write hook_update.
lawxen’s picture

lawxen CreditAttribution: lawxen at Sparkpad commented
Status: Active » Needs work
hchonov’s picture

hchonov
Primary language Bulgarian
Location 🇪🇺🇩🇪🇧🇬
CreditAttribution: hchonov as a volunteer and at bio.logis Genetic Information Management GmbH commented
Component: entity_reference.module » field system

Moving to the field system component.

Review of #14:
We cannot remove the reference by ID until D9 and we should not change the schema as well. Instead we should add an option for new fields, whether they will use reference by ID or reference by UUID - "reference_type", while leaving the reference by ID the default option until D9. This leads to naming the new property "target_uuid". The returned columns and properties then should depend on the setting "reference_type". An entity reference field in D8 will become more complex when conditions in entity queries are build for it, therefore it would be nice if we add explicit API methods for retrieving the reference type e.g. - EntityReferenceFieldItemListInterface::isReferenceByID() and EntityReferenceFieldItemListInterface::isReferenceByUUID().

lawxen’s picture

lawxen CreditAttribution: lawxen at Sparkpad commented

@hchonov
Thanks for the advice
I fully agree with your idea, Because the change of #14's hook_update is huge.
Entity's 'type' field, Node's uid, revision_uid fields..... entity_reference exits everywhere, Drupal8 can't bear this kind of changing.

Instead we should add an option for new fields

I will do this in the next step, Just allow new field to select the storage mode.

lawxen’s picture

lawxen CreditAttribution: lawxen at Sparkpad commented
Assigned: Unassigned » lawxen

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

lawxen’s picture

lawxen CreditAttribution: lawxen at Sparkpad commented
Title: Use UUID in entity reference values instead of the entity's ID » Add a choice to use UUID in entity reference values instead of the entity's ID
Issue summary: View changes
mstef’s picture

mstef CreditAttribution: mstef commented

Would be great to supply a migration for existing fields that want to switch to UUID as well (once this gets done).

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Issue tags: +API-First Initiative

Also relevant to API-First. (Discovered via #2951093-2: Support alphanumeric entity IDs and config entities.)

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Consensus Enterprises, Colan Schwartz Consulting commented
Related issues: +#2761157: Have Views' taxonomy term filters use UUIDs instead of entity IDs
lawxen’s picture

lawxen CreditAttribution: lawxen at Sparkpad commented
Assigned: lawxen » Unassigned

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm at OSInet commented
Related issues: +#2957611: Remote Entity Reference

For the record, this ties in with module @laxwen's Remote Entity Reference, https://www.drupal.org/project/remote_entity_reference

Mykola Dolynskyi’s picture

Mykola Dolynskyi
Primary language Ukrainian
Location Poltava
CreditAttribution: Mykola Dolynskyi commented
Related issues: -#2957611: Remote Entity Reference

+1 for having opportunity to use UUID as primary ID, with migration mechanism, in D9 core

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.