Smart inwalidacja — głębsze omówienie

Smart inwalidacja to tryb domyślny. Zamiast purgować “wszystko związane z produktem X”, gdy produkt się zmienia, sprawdza, które pola faktycznie się zmieniły, i wylicza minimalny zestaw tagów cache, które muszą umrzeć.

Ta strona wyjaśnia mapowanie pole-do-tagu, byś mógł przewidzieć, co dany save zinwaliduje — i zdecydować, czy Smart jest dobry dla Twojego sklepu.

Dlaczego poziom pól ma znaczenie

Standardowa inwalidacja Shopware działa na poziomie encji: jakakolwiek zmiana produktu X inwaliduje wszystko otagowane product-X. Ten tag jest zwykle przypięty do:

Strony detalu produktu
Każdej strony kategorii, na której produkt się pojawia
Każdego query listingu, który zwrócił produkt
Komponentu async buybox
Strony głównej, jeśli produkt jest featured

Więc jednoznakowa poprawka w opisie re-renderuje tuziny stron — z których wiele nawet nie wyświetla opisu.

Tryb Smart rozbija tag encji na zestaw tagów per pole. Listingi noszą product-X.name + product-X.price + product-X.coverImage; strony detalu noszą pełny zestaw; buybox nosi product-X.price + product-X.deliveryTime + product-X.stock. Zmiana tylko opisu matchuje tylko zestaw tagów strony detalu, więc tylko ten jeden wpis jest purgowany.

Przykłady

Zmienione pole na produkcie	Smart inwaliduje
`name`	Detail + listingi (name pokazany w kartach) + strony kategorii (odniesienia w breadcrumb)
`description`	Tylko detail
`price`	Detail + listingi + buybox + home (jeśli featured)
`stock`	Detail + buybox
`deliveryTime`	Tylko buybox
`coverId` (cover image)	Detail + listingi
`metaTitle` / `metaDescription` / `keywords`	Tylko detail
`categoryIds` (zmiana przypisania)	Detail + każda stara i nowa strona kategorii + listingi
`active`	Detail + listingi + strony kategorii
`properties` (przypisanie)	Detail + agregacje filtrów
`visibilities` (przypisanie kanału sprzedaży)	Detail + listingi + strony kategorii w dotkniętych kanałach

Zmienione pole na kategorii	Smart inwaliduje
`name`	Strona kategorii + listingi nadrzędne + menu nawigacji
`description`	Tylko strona kategorii
`parentId` (przenoszenie)	Stare i nowe drzewa kategorii + menu nawigacji
`active`	Całe drzewo pod nią
`productAssignmentType` / `productStreamId`	Strona kategorii + listingi

Zmienione pole na stronie CMS	Smart inwaliduje
`name` / `sections` / `slots`	Wpis strony CMS
Przypisanie do kategorii	Strona kategorii + strona CMS

Pola custom

Pola custom są konserwatywnie kubełkowane — inwalidują stronę detalu plus listingi, jeśli pole custom pojawia się w bloku properties typowo pokazywanym na kartach.

Jeśli masz pole custom, które kontroluje tylko output strony detalu (np. blok rich-text “warranty”), Smart i tak traktuje je domyślnie jako listing-affecting, by być bezpiecznym. Nadpisz mapowanie, jeśli wiesz lepiej — zobacz sekcję Rozszerzanie Smart poniżej.

Kiedy Smart over-purguje (a kiedy nie)

Smart jest konserwatywny. W razie wątpliwości purguje więcej, niż ryzykuje pozostawienie stale strony. Przypadki, gdzie celowo over-purguje:

Bulk import produktów przez DAL — Shopware fire’uje write eventy z pojedynczym payloadem “wszystko zostało ustawione”. Smart nie może powiedzieć, które pola efektywnie się zmieniły, i purguje wszystko.
Pierwszy save po migracji — ten sam powód co wyżej.
Nieśledzone pole, którego wartość ma znaczenie — np. dodałeś macro Twig do swojego theme, które czyta nieśledzone pole custom. Smart nie wie, że Twój theme to czyta, więc nie spurguje listingów, gdy to pole się zmieni.

Dla dwóch pierwszych spodziewaj się jednorazowo dużego purge po dużych importach. Dla trzeciego przełącz na Precise lub Extended dla tego konkretnego save’a, lub dodaj ręczny purge ze skryptu importu.

Przypadki, gdy Smart jest złym defaultem

Prowadzisz stronę treści, nie sklep — treść rzadko się zmienia; over-purgi z Precise / Extended nie są warte narzutu analizy.
Zawsze robisz bulk changes — Smart i Precise oba spurgują większość cache na bulk imports i tak; wybierz to, co produkuje mniej narzutu frameworka podczas analizy.
Twój storefront jest mocno spersonalizowany — większość stron jest i tak bypassowana; prostsze tryby są ok.

Koszt wydajnościowy

Field-diff jest wyliczany wewnątrz handlera eventu entity-written. Dla pojedynczego save’a produktu dodaje sub-milisekundowy narzut. Dla aktualizacji bulk narzut skaluje się liniowo z liczbą encji — zwykle pomijalnie w porównaniu z samym zapisem do bazy, ale widoczne w najgorszych profilach.

Jeśli analiza staje się bottleneckiem na bardzo dużych importach, przełącz na Precise na czas importu i z powrotem na Smart po.

Rozszerzanie Smart

Mapowanie pól Smart żyje w SmartInvalidationAnalyzer. Aby rozszerzyć z poziomu custom pluginu:

Dekoruj P2Lab\Cache\Service\SmartInvalidationAnalyzer własną implementacją.
Nadpisuj metody analyze<Entity>Change(array $changedFields): array, by zwracać własny zestaw tagów dla pól, których plugin nie zna.

Standardowe konwencje tagów są udokumentowane w Architektura.