Magento 2 – Good Practices for Saving Many Objects

databaseentitiesmagento-2.1magento2

I have a question regarding a good practice: how to correctly save many objects?

Let's assume I modified many entities in a collection, let's say a collection of Products. This is what I could do:

...

foreach($productCollection as $product{
    $this->productRepository->save($product);
}

...

However using the method save() in a loop is not only a bad practice but also highlighted by PHP CS. Of course, if the collection only contains 4 or 5 products it won't change the face of the world, but sometimes it is clearly most than that.

I know that if I only modify an attribute, I don't need to use the repository and can use the built-in Magento component to update attributes, however sometimes I also need to do some logic and really need the product entity.

So anyone has a good practice to share in this context?

Best Answer

If you have to do a mass update of one (or more attributes) to the same value, you can use:

$this->_objectManager->get('Magento\Catalog\Model\Product\Action')
    ->updateAttributes($productIds, ['status' => $status], $storeId);

In this example, we're updating all products matched by id ($productIds is array of product IDs), by setting their status attribute to the $status value, for store $storeId.

If you want just to update single attribute in the collection of products, you can use (in your case):

...
foreach($productCollection as $product{
    $product->addAttributeUpdate($attributeCode, $value, $store);
}
...

$attributeCode represents attribute name which has to be saved

$value represents the value which you want to set on the entity

$store represents store id, it can be $product->getStoreId()

Problem with addAttributeUpdate() is that updates attribute, but it doesn't update currently loaded product model. Take a look at the implementation in Magento\Catalog\Model\Product:

/**
 * Save current attribute with code $code and assign a new value
 *
 * @param string $code  Attribute code
 * @param mixed  $value New attribute value
 * @param int    $store Store ID
 * @return void
 */
public function addAttributeUpdate($code, $value, $store)
{
    $oldValue = $this->getData($code);
    $oldStore = $this->getStoreId();

    $this->setData($code, $value);
    $this->setStoreId($store);
    $this->getResource()->saveAttribute($this, $code);

    $this->setData($code, $oldValue);
    $this->setStoreId($oldStore);
}

In that case it's better to use something like, productResource is Magento\Catalog\Model\ResourceModel\Product :

...
foreach($productCollection as $product{
    // its sugessted to inject resource as dependency than using deprecated getResource() method. 
    // check reference for more information.
    // $product->getResource()->saveAttribute($product, $attributeCode);
       $this->productResource->saveAttribute($product, $attributeCode);
}
...

Lack of this solution becomes visible when you're working on large collections. That's why we have iterators which grabs data from database, one by one, and on that way, it prevents memory exhaustion.

...
$this->_dataObject = $this->_objectManager->get('Magento\Catalog\Model\Product');

$iterator = $this->_objectManager->get('Magento\Framework\Model\ResourceModel\Iterator')

$iterator->walk($productCollection->getSelect(), [[$this, 'walkCallback']]);
...

public function walkCallback($data)
{
    $this->_dataObject->reset(); // clean up shared object
    $this->_dataObject->setData($data['row']); // map data to product model
    $this->_dataObject->setDescription('test');
    $this->_dataObject->getResource()->saveAttribute($this->_dataObject, 'description'); // save only changed attribute instead of whole object
}

Those are ideas which you can use for manipulating collections.

Reference: https://github.com/magento/magento-coding-standard/pull/189

Related Solutions

Magento – Magento 2: best practice to add/delete product Images programmatically

It can be done using your second way, more or less like this:

<?php


namespace [vendor]\[moduleName]\Model\Adminhtml\Product\MediaGallery;

use \Magento\Catalog\Model\Product\Gallery\EntryFactory;
use \Magento\Catalog\Model\Product\Gallery\GalleryManagement;
use \Magento\Framework\Api\ImageContentFactory;

{

/**
 * @var \Magento\Catalog\Model\Product\Gallery\EntryFactory
 */
private $mediaGalleryEntryFactory;


/**
 * @var \Magento\Catalog\Model\Product\Gallery\GalleryManagement
 */
private $mediaGalleryManagement;


/**
 * @var \Magento\Framework\Api\ImageContentFactory
 */
private $imageContentFactory;


/**
 * @param \Magento\Catalog\Model\Product\Gallery\EntryFactory $mediaGalleryEntryFactory
 * @param \Magento\Catalog\Model\Product\Gallery\GalleryManagement $mediaGalleryManagement
 * @param \Magento\Framework\Api\ImageContentFactory $imageContentFactory
 */
public function __construct
(
    EntryFactory $mediaGalleryEntryFactory,
    GalleryManagement $mediaGalleryManagement,
    ImageContentFactory $imageContentFactory
)
{
    $this->mediaGalleryEntryFactory = $mediaGalleryEntryFactory;
    $this->mediaGalleryManagement = $mediaGalleryManagement;
    $this->imageContentFactory = $imageContentFactory;
}


/**
 * @param string $filePath
 * @param string $sku
 */
public function processMediaGalleryEntry($filePath, $sku)
{
    $entry = $this->mediaGalleryEntryFactory->create();

    $entry->setFile($filePath);
    $entry->setMediaType('image');
    $entry->setDisabled(false);
    $entry->setTypes(['thumbnail', 'image', 'small_image']);

    $imageContent = $this->imageContentFactory->create();
    $imageContent
        ->setType(mime_content_type($filePath))
        ->setName('test')
        ->setBase64EncodedData(base64_encode(file_get_contents($filePath)));

    $entry->setContent($imageContent);

    $this->mediaGalleryManagement->create($sku, $entry);
}

}

$filePath should be an absolute path - maybe you can use constans BP.

Magento 2 – Best Practices for Using/Avoiding Magic Getters

The above question is about using magic methods vs. getDataByKey or getDataByPath. I think there is a third option, too, and that is implementing real getter and setter methods.

The getData* methods all have the downside that they have to be annotated for type inference to work.
Usually that is done with a /* @var string $foo */ annotation above the getData* call.
This is a bit smelly, because the type of the data should be declared in the class that contains the data, not the class that calls getData*.
The reason for that is that if the data changes, the class is the most likely to be updated, not all getData* call sites.
That is why I think real methods increase maintainability compared to using getData* accessors.

So I think it boils down to a trade off between maintainability and quicker implementation (less code to write).

Luckily, nowadays IDEs are really good at creating the getter and setter implementations for us, so that argument doesn't really apply any more.

One more argument against magic getters and setters that is missing from the question above is that it's not possible to create plugins for them.

The only other value I think I can add to the topic is trying to collect the reasons to use or not to use @method annotations, if implementing real methods is out of the question for some reason.

Pros

A @method annotation is a little less code to write compared to implementing a real getter and setter. This is barely true though nowadays because IDEs are good at generating accessor methods, so that's not a real benefit any more.

Cons

It's easy for things to go wrong.
- Annotations are comments, they become obsolete easily when code evolves but the annotations are not updated. Real methods are more robust.
- It's possible to add multiple annotations with different type signatures without an interpreter error - static code analysis behavior is undefined, and it can lead to subtle bugs that are hard to track down.
- If both a @method annotation and a real method with the same name exist, the annotation type signature overrides the real method during static code analysis, which is the opposite of what the PHP interpreter does. This again can easily lead to subtle bugs.

For the above reasons I personally do not use @method annotations if I can avoid them.
For code that is intended to live long I implement real getter and setter methods. The maintainability gain is worth the effort of triggering the IDE to generate them.

For more experimental code during a spike, or for a simple implementation detail of a module I use getData* methods, too, because I'm lazy.

Best Answer

Related Solutions

Magento – Magento 2: best practice to add/delete product Images programmatically

Magento 2 – Best Practices for Using/Avoiding Magic Getters

Related Topic