Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hi there! ^_^
For my use case I am leveraging external_entities + external comment + with a custom CKAN + Solr client and everything is working great with a few minor patches. The one issue I am having is when inspecting queries via jsonapi I noticed the the UUID for my external entities along with when the external entity is included as a resource the UUID keeps changing. Instead I just wanted the UUID to be the "id" represented stored in both CKAN + Solr. This then resolved my UUID issues and I am able to fully leverage jsonapi with comment crud.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | external_entities-add_uuid-2882887-11.patch | 1.68 KB | rp7 |
Comments
Comment #2
sylus CreditAttribution: sylus commentedComment #3
rp7 CreditAttribution: rp7 for Government of Flanders commentedGood question why this is explicitly being prevented. I don't immediately see the reason. I tend to follow you & make this possible (again). Anyone else has an opinion about this?
Was added in one the very first commits (https://cgit.drupalcode.org/external_entities/commit/?id=33225962d6b30ba...).
Comment #4
Wim LeersI think the idea was perhaps that external UUIDs aren't necessarily trustworthy? i.e. if UUIDs aren't actually universally unique, then conflicts are likely.
But obviously that prevents this use case.
I think this patch is fine.
Comment #6
rp7 CreditAttribution: rp7 for Government of Flanders commentedComment #7
rp7 CreditAttribution: rp7 for Government of Flanders commentedMoving this issue to 2.x. Patch attached adds the uuid field to external entities.
Comment #8
rp7 CreditAttribution: rp7 for Government of Flanders commentedSide note to the patch above: this makes the UUID field mapping required when adding/editing an external entity type. Unsure if we actually want this? Not mapping a UUID will break compatibility with JSON API FYI.
Comment #9
Wim LeersHm, this is tough. Generally speaking, UUIDs are to be preferred over IDs. Which is why JSON API requires them. But of course not every external entity type has one necessarily. UUIDs have pretty strict format requirements, IDs do not. I wonder if we can reliably compute a UUID using the external entity's ID as a seed.
Comment #10
rp7 CreditAttribution: rp7 for Government of Flanders commentedI guess its possible, some interesting links:
But that would add some complexity to the module.
Another option is to make the UUID mapping non-required. We provide events for altering the mapping of raw data to entities. If someone requires a UUID for an external source which doesn't offer one, it can be done.
Comment #11
rp7 CreditAttribution: rp7 for Government of Flanders commentedPrevious patch missed something (the base field definition). Patch makes it possible to map a UUID & the mapping is not required.
Comment #13
rp7 CreditAttribution: rp7 for Government of Flanders commentedSetting this issue to fixed. UUID mapping is now possible, although not required.
As earlier suggested - if one has the need to map a UUID while the external source is not offering one, it can be done by altering the mapping of raw data to entities.