Custom attributes do not work as intended

[samtay]

See below example

$product = $this->productRepository->get('test-sku');
// $product->getCustomAttribute('custom_attr_code')->getValue() == 0
$product->setCustomAttribute('custom_attr_code', 1); // changing value from 0 to 1
$this->productRepository->save($product);
// $product->get('custom_attr_code') == 0
// and $product->getCustomAttribute('custom_attr_code')->getValue() == 0

ANY values in $_data[self::CUSTOM_ATTRIBUTES] is lost, and not saved properly.

This is because the product repository issues a product model load which loads all attributes, custom or not, into the _data array. Anytime the app calls ProductInterface::getCustomAttributes (which it does try to do when saving, to grab any values there) any custom attribute 'key' in $_data['custom_attributes']['key'] is overwritten because that key exists in $_data['key']. This overwriting happens here.

[samtay]

Note: This is a larger issue for those leveraging the webapi data object input converter. That converter will throw exceptions when any input keys reference attribute codes not present in the ProductInterface schema, hence they must be set in a nested $inputData['custom_attributes'] node. But, once nested there, that data will never be saved.

[adragus-inviqa]

I'm not sure of the issue, but I think they do work, but they're a bit confusing. Maybe you can find something useful in this discussion: http://magento.stackexchange.com/questions/87452/how-do-the-extension-attributes-work-in-magento-2

[Vinai]

Are you sure the products attribute set contains the custom attribute, and that the attributes property is_user_defined is 1?
I found once I get those right it works, at least for customers, and I think for products, too, iirc...

Note: this is about custom attributes, not extension attributes, right?

[adragus-inviqa]

Note: this is about custom attributes, not extension attributes, right?

Correct, but there's some mentioning about custom attributes in that SO link, too.

[samtay]

Yes @Vinai the attributes are user defined and set up properly. See the code I linked above, it is very clear that anything set via setCustomAttribute($key, $value) is overwritten. The only way to get data to save on products is to have the data in the $_data property directly via setData($key, $value), but at that point you are not coding against the interface.

[samtay]

Bump. I don't think core team realizes this is a rather large oversight which makes the entire webapi for EAV entities close to useless. Should be a high priority.

[andimov]

@samtay, thank you for reporting. Please, provide the used version. If the problem is actual for a specific tag, please, specify it and be sure that the latest update was used.

[samtay]

I found it on EE 2.0.7 but it still exists on the CE develop branch.. just look at the code link I posted in my initial comment, it should be obvious.

[andimov]

@samtay
Thank you.
If you think that this is a bug, please provide description according to the template

[samtay]

Step 1.

Clone Magento2 from any version since general availability.

Step 2.

Set up access to product repository API such as through test framework/module

Step 3.

[Insert original issue comment]

The only way to have these work as intended is to use a builder such as \Magento\Catalog\Api\Data\ProductInterfaceFactory and set sku along with any data changes. While that might seem like an easy work around, the product repository is central to the app and it seems like a bad idea to leave this fragility in place.

Recap

Any time a product model load is issued (such as during ProductRepository::get), all of the custom attributes are loaded directly into the _data array. Thus any further usage of custom attributes interface methods are useless because once a custom attributes key exists in the _data property, it will always be preferred over the _data['custom_attributes'] array.