Wpis z mikrobloga

Szczególnie wydając bundle nie warto robić takiej pokręconej logiki jak tworzenie własnych komend wywołujących wbudowane ;)


@kiler129: I vice-versa, wywołując cache:clear spodziewasz się, że usuniesz tylko cache z symfony2. W dodatkowych bundle'ach jest po prostu oddzielna komenda do czyszczenia cache'u tworzonego tylko przez tego bundle'a.
@JackBauer: Czym jest cache Symfony? Czy profiler to jeszcze symfony czy osobny komponent? :)
Przy wywołaniu cache:clear cache doctrine czy sonaty również znika.

$ php70 app/console cache:clear --no-warmup
Clearing the cache for the dev environment with debug true
$ ls app/cache/

Sama dokumentacja do kernel.cache_clearer mówi:

If your bundle caches files, you should add custom cache clearer for clearing those files during the cache clearing process.


@stacktrace: @uirapuru: O,
@kiler129: Przyznam, że nie zauważyłem, że podałeś link do tagów (facepalm) i myślałem, że chodzi o nadpisanie usługi. Teraz spojrzałem i faktycznie masz rację.

należałoby filtrować sobie ręcznie tylko dla cache:clear, co jest mało eleganckie

Natomiast co do tego nie mogę się zgodzić bo implementacja zdarzeń w Symfony po prostu tak działa, że bardzo często trzeba filtrować.
@stacktrace: To na pewno, ale dodają już coraz więcej specyficznych eventów. Z drugiej strony w miarę rozszerzania frameworka jest on coraz wolniejszy (a Symfony i tak do demonów prędkości nie należy) ( ͡° ʖ̯ ͡°)
@kiler129: A co konkretnie dodatkowo chcesz robić przy czyszczeniu kesza?

* Dorzucić zrzucanie jakichś swoich keszy? Jeszcze spox, choć mnie by trochę myliło, bo siadam do appki Symfonowej do zakładam, że to polecenie zrzuca właśnie Symfonowe kesze. Lepiej oddzielne polecenie, np app:clear-cache
* Zupełnie coś innego? Zdecydowanie nie dokładaj tego do zrzucania keszy, bo już w ogóle kiedyś będzie problem ze zdebugowaniem co się tu odwala. Rób swoje, oddzielne polecenie.

Jeśli
@MacDada: Czyszczenie cache bundle - po prostu po wyczyszczeniu cache Symofny i nie wyczyszczeniu cache mojego bundle moga występować dziwne i nieprzewidywalne zjawiska.

@kiler129: No to IMHO:

1. Na pewno zrób do tego dedykowane polecenie.
2. Dodatkowo możesz się podpiąć pod Symfonowe.

Ad2: tak jak już znalazłeś, podpiąć się tu: http://symfony.com/doc/current/reference/dic_tags.html#kernel-cache-clearer

Choć grepowałem ten tag i nie widzę, żeby cokolwiek się podpinało, do tego ./app/console debug:container --tag=kernel.cache_clearer zwraca pustkę.

Przy wywołaniu cache:clear cache doctrine czy sonaty również znika.


Bo ładują się grzecznie do katalogu cache, a jego zawartość jest po prostu usuwana ;-)
@MacDada: Faktycznie - masz rację z tym usuwaniem całości.
Ja przyjąłem bezpieczniejszą technikę - usuwam tylko pliki i foldery które mógł utworzyć kod, tak jakby ktoś przypadkiem ustawił katalog cache na .. Niestety nie mogę użyć standardowego katalogu cache bo potrzebuję mieć dostęp do niego z http ;)

Osobną komendę też dodam - to mus, nie zawsze chce się czyścić całość.
tak jakby ktoś przypadkiem ustawił katalog cache na ..


@kiler129: Jak może to zrobić „przypadkiem”? Na podstawie czego decydujesz nazwę katalogu?

Symfony nie waliduje tego w żaden sposób na poziomie zrzucania, po prostu zaciąga z konfiguracji i ufa, że wartość jest prawidłowa.

Skąd jest ta wartość? Jest tworzona na podstawie zahardkodowanej nazwy katalogu (cache) i środowiska (env) – to drugie raczej nie będzie zawierać .. ;-)

ALE,
@MacDada: Historia pokazuje, że rekursywne usuwanie drzewa czasami źle się kończy (na linuksie kojarze dwie wpadki - steama z home directory i chyba nvidii z /var).
Stąd właśnie używam metod które listują pliki które tworzy sam bundle i tylko je usuwam - patrząc na pattern to nawet gdyby ktoś ustawił sobie /home/ to by wielkiej krzywdy nie zrobił.

Po co Ci dostęp do katalogu cache przez web?

Cały sęk polega na
@kiler129: OK, to ja bym patrzył na to jak na Assetica => tworzy sobie faktycznie różne rzeczy w katalogu publicznym, kasuje je, etc.

Pytanie, czy faktycznie nazwa katalogu musi być konfigurowalna? Jeśli tak, to jakim mechanizmem?

* Jeśli nie musi być konfigurowalna, to hardkodujesz (czy tam masz jakąś stałą/funkcję/etc co ją dostarczy) i tej wartości ufasz.
* Jeśli sama nazwa katalogu jest konfigurowalna, to ogranicz nazwy do a-z i waliduj (resztę
Pobierz MacDada - @kiler129: OK, to ja bym patrzył na to jak na Assetica => tworzy sobie fakt...
źródło: comment_7qJsv8Pafxvbk9ymUbsKh40bu76SGkil.jpg
@kiler129: Choć z drugiej strony (jeśli masz nazwy plików w bazie i tej informacji ufasz), to faktycznie usuwanie pojedynczo plików będzie bezpieczniejsze przy konfigurowalnym katalogu. Tak czy inaczej, jeśli katalog musi być konfigurowalny, to go waliduj. Jeśli nie, to olałbym i czyścił wszystko w środku (bo szybsze i mniej kombinacji w kodzie).