Currently with Drupal 8 a UUID is useless. It maybe universally unique, but it doesn't really identify anything on it's own.

In Multiversion module there is multiple entity indexes for UUID, revision hash, sequence, and revision tree. All but UUID are irrelevant for core at the moment.

In Multiversion all of the indexes are grouped by workspace, which is important for how Multiversion uses these indexes. If we put indexes into core before workspaces go into core we will need to find a way for contrib modules like Multiversion to alter these indexes.

Proposed resolution

- Create an interface for all indexes
- Create a base class for all indexes
- Create an index of UUIDs with their entity type, entity id and revision id.

Remaining tasks

This is already implemented in Multiversion module, so mostly just needs porting over. However Multiversion introduces workspaces which would need to be removed from the uuid index code in a way that still allows Multiversion to add them.

Technical summary

- entity.index.uuid service
- getters and setters in service
- hook_install to add all existing entities to index
- hook_entity_insert to add new entities to index

How the indexes in Multiversion are used

The main use case is the RELAXed Web Services module which implements the CouchDB API ( this API focuses 100% on UUIDs, so we need a way to know when GETting or POSTing a URI which entity that relates to without looping through every entity type.

Other use cases

#2353611: Make it possible to link to an entity by UUID - Wouldn't it be cool if we didn't need the entity type in the URI, and out UUIDs were universally identifiable?
#2577923: Menu link content entities that point to nodes are not deployable - Wouldn't it be cool if menu links could link to a UUID and we can look up what entity type that relates to?


timmillwood created an issue. See original summary.

amateescu’s picture

I was thinking about this in the past few days and I couldn't quite figure out what is the use case for the UUID index as it is currently provided by the Multiversion module. Is it really useful to find an entity by UUID without knowing the entity type?

For core, I think we could do something more like the taxonomy index but for each entity type. It would be something like this:

- each content entity type that is referenced by an entity reference field will get its own index table (this is needed in order to be able to provide extra columns per entity type, e.g. 'status', 'sticky', 'created' from the current taxonomy index)
- we do not exclude "inaccessible" entities like the taxonomy index does
- we include UUIDs alongside numeric IDs for both referencing and referenced entity

What do you think?

timmillwood’s picture

Issue summary: View changes
catch’s picture

Yes I'm also not clear on the use case here, tagging for issue summary update.

timmillwood’s picture

Title: Create an index of UUIDs » [PLAN] Create an index of UUIDs
Issue summary: View changes
Issue tags: -Needs issue summary update

The biggest use case for this in Multiversion is the Relaxed module.

Relaxed is an implementation of the CouchDB API ( a CouchDB database relates to a Workspace, and a CouchDB docid relates to a Drupal entity UUID. Therefore we need to be able to GET URLs like /{db}/{docid} without knowing the entity type. We also need to POST to these types of URL for this we have a bunch of normalizers in the Replication module which handle the normalization and denormalization of entities.

There are many many other places in these modules, especially in the normalizers, where we use the indexes to get entity information from just the UUID or revision hash or sequence id etc

larowlan’s picture

Is there any technical reason those document IDs can't contain the entity type as well.

I.e. do they need to be UUIDs in the strict form of the word, or can they be in format {entity_type}:{uuid}?

timmillwood’s picture

I guess in theory they could be in the format {entity_type}:{uuid}

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.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.3.x-dev » 8.4.x-dev

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