11

I was wondering, what's the right way to implement an extensible EAV model.

I see that in Magento\Catalog\Model\Product, the method getExtensionAttributes() is implemented like this:

public function getExtensionAttributes()
{
    $extensionAttributes = $this->_getExtensionAttributes();
    if (!$extensionAttributes) {
        return $this->extensionAttributesFactory->create('Magento\Catalog\Api\Data\ProductInterface');
    }
    return $extensionAttributes;
}

But in others, like the customer or category models it's just

public function getExtensionAttributes()
{
    return $this->_getExtensionAttributes();
}

which can lead to a NULL result, if the extension_attributes key has not been set before.

Pragmatically, I would prefer the first one. This way I can always be sure to get an instance of Magento\Framework\Api\ExtensionAttributesInterface, even if the model has just been instantiated.

But why is it not used in other modules then? Is it against the new separation of data models that we see in the customer module? If so, how are we supposed to initialize the extension attributes?

2

I can partially answer my own question as I found out that the way the method is implemented in Magento\Catalog\Model\Product is definitely wrong and can lead to nasty bugs:

If there is no extension_attributes data yet, i.e. _getExtensionAttributes() returns null, the method returns an empty instance of the extension attributes interface.

This is good to fulfill the explicit contract and prevents "Call to a member function on null" errors but it always returns a new empty instance, which does not fulfill the implicit contract, namely that I get an extension attributes container for this specific instance.

That means:

$product->getExtensionAttributes()->setStockItem($stockItem);
var_dump($product->getExtensionAttributes()->getStockItem());

outputs:

NULL

A better implementation would look like this:

public function getExtensionAttributes()
{
    $extensionAttributes = $this->_getExtensionAttributes();
    if (!$extensionAttributes) {
        $extensionAttributes = $this->extensionAttributesFactory->create('Magento\Catalog\Api\Data\ProductInterface');
        $this->_setExtensionAttributes($extensionAttributes);
    }
    return $extensionAttributes;
}

But why is it not used in other modules then? Is it against the new separation of data models that we see in the customer module? If so, how are we supposed to initialize the extension attributes?

To that, I still don't have an answer

  • Github issue: github.com/magento/magento2/issues/5979 – Fabian Schmengler Aug 4 '16 at 7:46
  • Did you ever get an answer to this - or how's best to deal with it? I'm currently getting this issue while extending an order object . – ol'bob dole Nov 16 '17 at 14:04
  • @ol'bobdole, i was getting NULL for $order->getExtensionAttributes() and was resolved after getting order as below: $order = $this->orderRepositoryInterface->get($order->getId()); . Order repository interface is Magento\Sales\Api\OrderRepositoryInterface . Not sure if your issue was same – Sarjan Gautam Jun 8 '18 at 4:00
0

The code is used in different way in various extensions. The functionality is used to bind any attribute in that interface. For better understanding of this,refer this link : http://oyenetwork.com/articles/magento2-devliery-date-module-creation-from-scratch/

  • This article does not answer my question. I know how to add extension attributes to existing entities, I was asking specifically about the implementation of getExtensionAttributes() in custom entities – Fabian Schmengler Aug 4 '16 at 7:29

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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