0

I come from an SQL background and I'm still navigating fields/entities. I have a custom entity (analysis) to record information about a laboratory sample (what it is, when and where it was taken, and what analysis method was applied to it). The analysis will return many independent results. I was thinking of making a second entity (results) with an entity reference to the analysis entity, the name of the chemical that was measured, and the concentration that was measured.

However, could I instead make a custom field_type that is combination of the chemical name and its concentration? Then I could include this chemical_result as a field in my analysis entity with

->setCardinality(FieldStorageDefinitionInterface::CARDINALITY_UNLIMITED)

to include multiple chemical results in one analysis, right? When is it appropriate to use a custom field versus an entity?

I also have an entity called "chemical" that has information on chemicals of interest. If I use an entity for my results, I know I can make an entity_reference to the chemical entity, which would allow some more complex queries down the road. Can I do the same with a custom field? If not directly, I'm assuming I could program the add_analysis form to only allow certain values for chemical name when adding data to the result field, correct?

  • I'm not sure that storing the analysis data as a custom field type is going to be scalable. If you have many analysis items, then the results entity will load all of the analysis item data, which could have a performance impact depending on the size of the data. Entity reference will do the same except that the field data will be relatively small in comparison. Using views, it might not matter, because the entity references might load the entities anyway to view the data. – mradcliffe Dec 19 '16 at 17:43
2

Custom entities and custom fields are not mutually exclusive, you can use them together.

You can build a custom field type with more than one property. See for example the Password field which defines three properties:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Field%21Plugin%21Field%21FieldType%21PasswordItem.php/function/PasswordItem%3A%3ApropertyDefinitions/8.2.x

You can also extend the entity references field. See for example the File field:

https://api.drupal.org/api/drupal/core%21modules%21file%21src%21Plugin%21Field%21FieldType%21FileItem.php/function/FileItem%3A%3ApropertyDefinitions/8.2.x

The File field adds two properties to the reference field. In your case you would add the properties chemical name and concentration to a reference field which points at the analysis entity.

  • You're suggesting something a little different that I was thinking. My thought was to make the analysis entity contain the sample information, and contain instances of results (chemical + quantity). It reads like your suggestion is to have two entities (analysis and results), where results uses a new field which combines a reference to the analysis, and the chemical. My idea would leave me with 1 entity and 1 custom field (or 2 entities and no custom fields), this is 2 entities and 1 custom field. What is the advantage of this over the original plans? – Kevin Nowaczyk Dec 19 '16 at 18:42
  • Extending entity_reference is a great idea either way. – Kevin Nowaczyk Dec 19 '16 at 18:44
  • I did not mean to suggest a data structure. I described how you can replace the second entity you mentioned in the question at the end of the first paragraph with a custom field. – 4k4 Dec 19 '16 at 18:56
  • Ahh, good. I'm used to thinking in terms of primary and foreign keys, so I was thinking you were suggesting that an alternate structure may have advantage despite reversed "directionality" of what I'm used to. – Kevin Nowaczyk Dec 19 '16 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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