I'm interested in using this module for a project of mine which has various "external" entities (eg. the entity storage is remote, API-based). While going through the code, in the DER 2.x install file I noticed the following comment:

// Only SQL storage based entities are supported.

Could you give a little more insight as to why this is? Is this by design? Is there a way around this limitation, and if so, could you point me in the right direction of the steps to take in order to make this work? Does this also apply to the 1.x version?

Comments

RaF7 created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2555027: Support non-numeric entity ID's

Note that the 1.x branch seems more production-ready than the 2.x branch. If we look at their respective latest releases:

I agree the reason behind this should be documented explicitly in the README.

In the 1.x branch, dynamic_entity_reference_views_data() says:

  // Ensure origin and target entity types are SQL.
  foreach ($entity_manager->getDefinitions() as $entity_type) {
    // \Drupal\views\EntityViewsData class only allows entities with
    // \Drupal\Core\Entity\Sql\SqlEntityStorageInterface.

So it appears that the reason only SQL storage based entities are supported is simply because Views can only query databases. So if you want to create views of your entities, including entities that have DER fields, those entities need to be stored in the database (== SQL storage).

In other words: as long as you don't care about Views support, it's also safe to ignore the SQL requirement.

AFAICT the key difference of 2.x vs 1.x is #2555027: Support non-numeric entity ID's — in fact, it's that issue that triggered the creation of a 2.x branch. This changed how DER fields stores target_id: it's now storing it as an int specifically only when the referenced entity type uses integer IDs. To enable MySQL/PostgresQL to execute queries to join them, i.e. for Views support.

Overall, it seems that as long as you don't need Views support, that entity types not using \Drupal\Core\Entity\Sql\SqlContentEntityStorage are fine?

(Pinging @jibran.)

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented
Status: Active » Closed (works as designed)

Overall, it seems that as long as you don't need Views support, that entity types not using \Drupal\Core\Entity\Sql\SqlContentEntityStorage are fine?

Yes, this is spot on.

1.x branch seems more production-ready

Yes, if you don't want to use it for numeric entity ID's.

2.x branch can be used on production site but Acquia had some issues with mysql triggers #2930423: MySQL triggers aren't supported on all hosting platforms. Also, 2.x overrides the query service for EFQ #2835542: Utilize service decorator instead of taking over entire EFQ service so it might not work if you are using https://www.drupal.org/project/workspace on your project. We also have an outstanding issue with 2.x basefields EFQ #2915512: Entity query doesn't allow relationship specifier for base entity fields.

That being said, I'm supporting both branches and 1.x is more suitable if you are using DER for advanced stuff. e.g. custom entities, basefields and etc. If your usage is simple enough e.g you only want to add configurable DER fields to the entities and you are not on Acquia then 2.x can be used without any issue. 2.x was branch added because of #2678756: Allow config entities to be flagged.

There is an upgrade path test from 1.x to 2.x and it is well tested and if at this point you are not confident enough to use 2.x then feel free to use 1.x because you can always upgrade to 2.x later.

Thanks, @Wim Leers for the reply and ping. Feel free to purpose the patch or project page update.