Wpis z mikrobloga

@NiktNieTroszczy: Własna komenda to nie problem (i tak będzie jedna). W ten sposób jest możliwe czyszczenie np. cache doctrine ale zależy mi właśnie na automatycznym czyszczeniu razem z cache aplikacji.
  • Odpowiedz
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.
  • Odpowiedz
@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
$
  • Odpowiedz
@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ć.
  • Odpowiedz
@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) ( ͡° ʖ̯ ͡°)
  • Odpowiedz
@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 chcesz mieć
  • Odpowiedz
@MacDada: Czyszczenie cache bundle - po prostu po wyczyszczeniu cache Symofny i nie wyczyszczeniu cache mojego bundle moga występować dziwne i nieprzewidywalne zjawiska.

  • Odpowiedz
@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ę
  • Odpowiedz
@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ść.
  • Odpowiedz
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
  • Odpowiedz
@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 tym,
  • Odpowiedz
@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ę ścieżki ustawiasz
MacDada - @kiler129: OK, to ja bym patrzył na to jak na Assetica => tworzy sobie fakt...

źródło: comment_7qJsv8Pafxvbk9ymUbsKh40bu76SGkil.jpg

Pobierz
  • Odpowiedz
@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).
  • Odpowiedz