0

I tried this answer:

https://drupal.stackexchange.com/a/298084/1082

But I can't seem to use

'field_scientists' => $entity_reference_uuid

where, in my case, field_scientists is a field of type Entity Reference UUID - which is a field type provided by https://www.drupal.org/project/entity_reference_uuid module

What happens for me is that I get nothing back, my results array from that example is empty.

Looking to do this programmatically in my own custom module, rather than use a Drupal View.

If there's another way e.g. that uses the ->query method for querying the database I'd be happy to use that programmatic approach.

Thank you.

Update

An example of a uuid of a node in my case is BMSSYS0000051988.

This was set in a migration import from a field in a CSV.

My attempts are:

1. based on the example in the other question: https://drupal.stackexchange.com/a/298084/1082

  $nodes = \Drupal::entityTypeManager()->getStorage('node')->loadByProperties([
    'type' => 'bol',
    'field_parent_uuid' => $taxonkey,
  ]);

2. db query

$query = \Drupal::entityQuery('node')
->condition('status', NODE_PUBLISHED)
->condition('type', 'bol');
$and = $query->andConditionGroup();
$and->condition('field_parent_uuid',  $taxonkey);
$query->condition($and);
$result = $query->execute();

where $taxonkey is BMSSYS0000051988

both 1 and 2 attempts above return an empty array.

Update 2

here is my migration config that shows uuid being written to from a field in the csv. Is this legal? Should a developer's code change the uuid value or should uuid only be handled by Drupal core?

dependencies: {  }
id: bol_csv_import
class: null
field_plugin_method: null
cck_plugin_method: null
migration_tags: null
migration_group: defaultl: publicbins
label: 'Import bol species data'
source:
  plugin: csv
  path: ./data/taxonomy_species_with_unpacked_bold.csv
  delimiter: ','
  enclosure: '"'
  header_offset: 0
  ids:
    - uuid
  fields:
    -
      name: uuidl: publicbins
      label: 'NBN id'
    -
      name: parent_uuid
      label: 'NBN id of parent'
    -
      name: name
      label: Name
    -
      name: rank
      label: 'Taxonomic Rank'
    -
      name: taxon_key
      label: 'Taxon Key'
    -
      name: authority
      label: authority
    -
      name: specimenrecords
      label: specimenrecords
    -
      name: publicrecords
      label: publicrecords
    -
      name: publicbins
      label: publicbins
    -
      name: taxid
      label: 'NBN Taxon ID'
process:
  title: name
  uid:
    plugin: default_value
    default_value: 1
  uuid: uuid
  field_parent_uuid: parent_uuid
  field_taxon_key: taxon_key
  field_authority: authority
  field_rank: rank
  field_num_bold_barcode_specimens: specimenrecords
  field_num_bold_public_records: publicrecords
  field_num_bold_public_bins: publicbins
  field_bold_taxon_id: taxid
  type:
    plugin: default_value
    default_value: bol
destination:
  plugin: 'entity:node'
migration_dependencies: null

Update 3

I'll write a db query to solve this issue. Running a command line sql indicates this approach could work:

MariaDB [db]> select * from node where nid = 246;
+-----+------+------+------------------+----------+
| nid | vid  | type | uuid             | langcode |
+-----+------+------+------------------+----------+
| 246 |  248 | bol  | NBNORG0000041189 | en       |
+-----+------+------+------------------+----------+
1 row in set (0.001 sec)
5
  • 1
    BMSSYS0000051988 is not a UUID.
    – 4uk4
    Apr 14, 2022 at 15:42
  • +1 Thank you @4uk4 that could be helpful uuid was set as that in the migration. When I do $node->uuid(); then BMSSYS0000051988 is what I get back. Do you know if uuid should be set by the developer's own code, or should it be only set by Drupal Core itself? Apr 14, 2022 at 16:42
  • I've added my migration config to my question to show how uuid was written to with BMSSYS0000051988. If this is "illegal" in that only Drupal core should manage and create/write uuids, then that would promote my strategy b) to implement a workaround to avoid using the uuid in this way: drupal.stackexchange.com/questions/310697/… Apr 14, 2022 at 16:48
  • 1
    No, it's not that only Drupal core should manage UUIDs. One of the main selling points is that UUIDs are unique world wide, so you can migrate them from site to site and they remain unique. But I wouldn't use the UUID field for other data than UUIDs. Put the non-UUID value in its own field and use UUIDs to cross reference data items in the source and/or destination of the migration. Where you create the UUIDs doesn't matter.
    – 4uk4
    Apr 14, 2022 at 18:25
  • +1 agree. I would prefer that the migration would not have imported that field data into uuid and instead another ordinary field. However I need to work with what I have, so in my 'Update 3', I will write a db query. Apr 19, 2022 at 8:34

1 Answer 1

0

In theory this should work, the field type sets the UUID as main property: EntityReferenceUuidItem:: mainPropertyName()

It might be that Drupal is confused and handling the field as a standard entity reference field because it extends the core field type.

To make clear which field property you are querying append it with a dot:

'field_scientists.target_uuid' => $entity_reference_uuid

Which should work for both, loadByProperties or an entity query:

->condition('field_scientists.target_uuid', $entity_reference_uuid)

The first is only a shortcut for the second using the same query engine.

10
  • I will try this out, this morning and get back to you - thank you so far. Apr 14, 2022 at 9:31
  • Unlucky I'm afraid. Array returned still empty. Apr 14, 2022 at 10:20
  • On basis that condition approach boils down to the same query engine, I would be inclined to not try that also, anticipating same issue instead do 2 things a) raise bug on drupal.org/project/entity_reference_uuid and b) implement a work around, create a new field in my content type which is a plain old entity reference (not with uuid), populate with a reference to a node and test the code again. If works, write script to populate rest of the nodes (there are 100K of them though). The populating will use the existing entity ref uuid field value to find the node for the new field. Apr 14, 2022 at 10:59
  • Is there a way to reproduce the issue on a fresh install? I couldn't. For me it works with and without the appended property name.
    – 4uk4
    Apr 14, 2022 at 11:42
  • 1
    $uuid = $node->uuid();
    – 4uk4
    Apr 14, 2022 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.