Upgrade the Collector module
Edit on GitHubUpgrading from version 5.* to version 6.*
- The general concept of
collectors
, andcollector queries
are enhanced to support multi-store. The following classes were altered to support the multi-store concept:
AbstractCollector
AbstractDatabaseCollector
AbstractPdoCollector
AbstractPropelCollector
AbstractSearchPropelCollector
AbstractStoragePropelCollector
AbstractCollectorQuery
Collector multi-store concept overview
- The primary change affects the
AbstractDatabaseCollector::processBatchForExport()
. Previously this method was responsible for simply exporting all “touch active” touched entities to Storage or Search. In multi-store environment, a multi-store entity does not necessary exist in all stores even though it is “touch active” in all stores. Moreover, an exported “touch active” multi-store entity can become invalid if it is unassigned from a specific store. To achieve the expected behavior, theAbstractCollector::isStorable()
method is introduced. Whenever this method returns withtrue
, the subject entity is considered to be available (in the current store) and will be exported. On the other hand, thefalse
return value that the entity is not available (in the current store) and either not should not be exported or should be deleted from Storage or Search if it has already been exported previously.
The AbstractCollector::isStorable
is not limited to multi-store entities and can be used on demand according to the above description.
-
The general “touch deleted” logic was updated through the
AbstractCollector::getTouchCollectionToDelete()
method which now always selects those records only fromspy_touch_storage
, andspy_touch_search
, which are related to the current store. -
StoreTransfer
is a new property which has been introduced forAbstractCollectorQuery
class and for its descendants. This property is populated before the actual query call through theAbstractPdoCollector
, andAbstractPropelCollector
classes. The property contains the current store as a transfer object. -
The propel abstract classes are amended to always select the current store specific
spy_touch_search
, andspy_touch_storage
records by amending the general prepare methods inAbstractSearchPropelCollector::prepareCollectorScope()
,AbstractStoragePropelCollector::joinStorageTableWithLocale()
, andAbstractStoragePropelCollector::joinStorageTable()
.
You can find additional details on the Collector module release page.
- Update/install
spryker/touch
to at least4.0.0
version. For more information, see Upgrade the Touch module. - If you have multiple stores: Amend your existing custom
AbstractPdoCollectorQuery
extended queries to always select current store relatedspy_touch_storage
andspy_touch_search
records. This has to be made for all of the queries regardless if they work with a multi-store entity or a single-store entity. You can find additional details regarding collector multi-store concept in the previous step, on the Collector module release page, and on our Demoshop implementation.
Example of a modified query
<?php
namespace Pyz\Zed\Collector\Persistence\Storage\Pdo\PostgreSql;
use Spryker\Zed\Collector\Persistence\Collector\AbstractPdoCollectorQuery;
class ProductConcreteCollectorQuery extends AbstractPdoCollectorQuery
{
/**
* @return void
*/
protected function prepareQuery()
{
$sql = '
SELECT
...
FROM spy_touch t
...
LEFT JOIN spy_touch_storage ON (spy_touch_storage.fk_touch = t.id_touch AND spy_touch_storage.fk_locale = spy_locale.id_locale AND spy_touch_storage.fk_store = :id_store)
WHERE
...
';
$this->criteriaBuilder->sql($sql)->setParameter('id_store', $this->storeTransfer->getIdStore());
}
}
It is important to add the condition to the LEFT JOIN
section so the number of result rows will not change.
-
The deprecated
CollectorDependencyProvider::provideLocaleFacade()
is removed, please check your code if you have custom calls or dependencies. -
The following methods have internal changes, please check if you have customized them:
AbstractTouchUpdater::bulkUpdate()
AbstractTouchUpdater::getCollectorKeyFromData()
You can find additional details on Collector module release page.
Upgrading from version 3.* to version 4.*
With version 4 of the Collector module, we fixed the collector:search:export
and collector:search:update
console commands to run for all available locales instead of just for the current one. This behavior is now consistent with the storage collector command (collector:storage:export
).
If you would like to upgrade to this version and you have multiple locales in your store, then you need to make sure that your collector query (in the Spryker Demoshop we use the ProductCollectorQuery
class) is also correctly filtered by locale, otherwise it could happen that you’ll have inconsistent data in your Elasticsearch.
Thank you!
For submitting the form