When using $storage->loadMultiple($ids) to load a large (say thousands) number of entities, a problem may happen when persisting those entities may break because the cache write back is just too large. For example using the core SQL cache driver, this causes the infamous MySQL "MySQL server has gone away" error, so annoying that attempts to avoid it have their own documentation page at
https://www.drupal.org/node/259580 →
max_allowed_packet = 64M (default is 4M)drush genc --bundles=article 10000 0drush core-cli$s = Drupal->entityTypeManager()->getStorage('node');drush cr$s->loadMultiple();INSERT INTO cache_entity SQL query with its multi-thousand placeholder and values (some/most development configurations and small/untuned MySQL/MariaDB servers).Note that:
$this->setPersistentCache($entities_from_storage);max_allowed_packet = 1024M from its default 4M, but this is not recommended considering issues like response time, message fragmentation increasing error likelihood, and especially congestion on the server during those single huge queries. Better split huge requests to a few more more reasonably sized queriesSplit the cache insertions in ContentEntityStorageBase::setPersistentCache to a reasonably sized loop on $this->cacheBackend->setMultiple() on chunks of items, instead of a single call passing the unlimited quantity received, probably splitting the list with a loop on array_chunk($items).
It may also help with other cache drivers.
Quantify the situations where this happens to ascertain severity and what a "reasonable" chunk size is, possibly introducing a setting.
None.
None.
None, unless we add a setting, in which case the extra setting can be considered a tiny model addition.
Not applicable yet.
Actually appears to be a duplicate of 🐛 Chunk multiple cache sets into groups of 100 to avoid OOM/max_allowed_packet issues Fixed .