I've given this careful thought because the $line_item->order_id backreference is very painful in 1.x, especially during importing.

I experimented with a computed field, where the reference would be computed on demand by doing an EntityQuery (basically the same thing our 1.x search api integration for products does). However, I disregarded this because I feel that the use case is too frequent to justify the performance penalty of having to run a query to get the id.

In the end I decided to go with an entityreference base field ($lineItem->order and $variation->product) that has getters only, and is populated by the parent entity's postSave() method (that way the parent id is always available). This means that we're as fast as before, but the backreference is controlled and maintained by the parent entity, which means that the developer should never need to care about it, not even when importing.

Comments

bojanz created an issue. See original summary.

  • bojanz committed c8efe85 on 8.x-2.x
    Issue #2557477: Add line item -> order and product variation -> product...
bojanz’s picture

Status: Active » Fixed

Had to go with $line_item->order_id and $variation->product_id because "order" is a reserved keyword and Drupal core doesn't quote those (yet). I'll open an issue to revisit that.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.