[gajowy_marucha]

#doctrine #symfony #php

Mam takie coś:

/**
*
* @ORM\PreRemove
*/
public function groupSizePreRemove()
{
$this->getCosting()->resetOpenBandOppositeRateType();
}

/**
* @ORM\PostUpdate
*/
public function groupSizePostUpdate()
{
$this->getCosting()->resetOpenBandOppositeRateType();
}

potem w kontrolerze wołane jest persist i flush przy remove oraz tylko flush przy update.

Pytanie: Dlaczego zmiana w innym entity (costing) zapisuje się do bazy przy preRemove ale przy preUpdate lub postUpdate jest ignorowana?

[kaesx]

@gajowy_marucha: jak robisz update, to zmiana nie zapisuję się tylko jak robisz pusty update (nic się nie zmienia), czy zawsze? Miałem podobnie przy pustych update, wystarczyło zaktualizować jakiekolwiek pole np. znacznik czasowy updatedAt i wtedy postUpdate wykonywał się be problemu.

[gajowy_marucha]

@kaesx: wlasnie event dziala dobrze, pole w entity costing jest zmienione ale potem sie nie zapisuje do bazy :/
To podstawowe entity ktorego robie update tez jest zawsze zmieniane wiec kompleteni nie wiem o co biega.

[kaesx]

@gajowy_marucha: A w relacjach Masz prawidłowo ustawione inversedBy, mappedBy?

[gajowy_marucha]

@kaesx: raczej tak, bo przecież wtedy by ten sam kod nie działał wywoływany z preRemove? A dla preRemove wszystko śmiga...

[kaesx]

@gajowy_marucha: a zamień na chwilę event postUpdate na preUpdate i daj cynk czy działa.

[gajowy_marucha]

@kaesx: no pisałem w pierwszym poście że ignorowane jest dla obu...

[kaesx]

@gajowy_marucha: możesz mi puścić obie entity na priv?

[gajowy_marucha]

@kaesx: korzystam dość intensywnie z dziedziczenia musiałbym Ci połowe klas wrzucić:)

Jest tak: Robie remove entity A i wtedy w preRemove robię update dla niektórych elementów klasy C w kolekcji entity klasy B :) Wtedy działa. Dla update entity klasy A nie działa.

Pewnie nie rozjaśniłem :) no nic, draze dalej, pewnie to problem z cache czy co....

[kaesx]

@gajowy_marucha: raczej nie w cache bym szukał winnego :) miałem kiedyś podobny problem pamiętam - też zachodziłem w głowę o co biega i jeśli nie mylę się eventy nie wywoływały się, kiedy nic się nie zmieniało. U mnie pomogło dodanie aktualizacji znacznika czasowego w preUpdate, czy tam postUpdate.

[gajowy_marucha]

@kaesx: tu jest podobny problem

[kaesx]

@gajowy_marucha: jeszcze możesz to obejść pisząc FlushListenera dla tej encji.

[gajowy_marucha]

@kaesx: ogarnąłem to w końcu. Może ci się przyda:
Przede wszystkim nie doczytałem do końca dokumentacji ᕙ(⇀‸↼‶)ᕗ

hanges to associations of the updated entity are

[kaesx]

@gajowy_marucha: najważniejsze, że działa. A jeśli nie chcesz używać entityManager w encji, zainteresuj się Listenerami. Tutaj masz linka: http://mightyuhu.github.io/blog/2012/03/27/doctrine2-event-listener-persisting-a-new-entity-in-onflush/ - mi to było potrzebne co prawda w innej sytuacji, ale tak na szybko wydaje mi się, że tu też się sprawdzi :)

[gajowy_marucha]

@kaesx: Używam listeners, nawet teraz przenoszę to do mojego EntityListener. Problem z listenerami mam taki że ta logika będzie "|gdzieś tam z boku" i łatwo zapomnieć że coś takiego się dzieje przy update akurat tego enituty. W ciele Encji wszystko jest jak na dłoni.

[DanioPL]

@gajowy_marucha: nie używa się lifecycle events w encjach i model oparty na eventach to zazwyczaj sporo kłopotów w późniejszych fazach projektu. Jeśli nie wierzysz randomowej osobie z internetu ( ͡° ͜ʖ ͡°) to posłuchaj jednego z twórców narzędzia z którego korzystasz: https://vimeo.com/154091776

[gajowy_marucha]

Dzięki, oglądnę później. A wyjaśnia może po co one tam są skoro nie można z nich korzystać? :)
No bo nawet w dokumentacji to jest na encjach tłumaczone...

[gajowy_marucha]

@DanioPL:

[DanioPL]

@gajowy_marucha: to takie serialize-unserialize dla ORM, w okolicach 20 minuty jakoś o tym mówi. Źle się wyraziłem, używa się tego na encjach, ale na 99% przypadków można i powinno się uniknąć. Z własnego doświadczenia i obserwacji rozwoju innych programistów sprawa wygląda tak: nie znasz eventów -> poznajesz eventy -> "ej to zajebiste użyjmy tego do operacji przed usunięciem" -> "dorzućmy jeszcze preupdate" -> "ej #!$%@? osochozi, czemu to się zmienia/nie

[gajowy_marucha]

@DanioPL: wiesz co pod skórą czułem że te eventy mogą być zwodnicze, szczególnie jak jest milion listenerów i każdy ma tam coś z logiki biznesowej. Dlatego starałem się trzymać wszystko w encjach.
Chyba jestem na etapie "nie ogarniam kuwety:)"

[MacDada]

groupSizePreRemove()

@gajowy_marucha: Unikaj w encji nazw typu PreRemove – nie ma znaczenia, że odpalasz to akurat przed usunięciem. Możesz przecież normalnie „ręcznie” odpalić sobie tę metodę z usługi czy kontrolera, więc wystarczy w nazwie samo groupSize(), bez wskazywania „kiedy”.

groupSizePreRemove