[spike200]

Musiałem zrobić refactoring i pozamieniać wszystkie boolean w bazie z isCancelled na pole daty dateCancelled. I to mialoby dzialac jako flaga, jesli date_cancelled IS NULL znaczy ze isCancelled = 0;

Problem zaczyna się w kodzie, jest sporo miejsc, gdzie użyty jest zwykły findBy oraz findOneBy. Nie wspierają one jednak IS NULL czy IS NOT NULL i nie ma szans sprawdzić czy encja jest cancelled czy nie jeśli polem jest data.

Można dodać metode do repo, ale problem jest taki, ze tych metod musialoby byc duzo. FindBy uzyte jest w wielu miejscach w roznych konfiguracjach, filtruje rozne pola, nie tylko isCancelled. Dodatkowo, refactoring obejmuje ok 5 encji, więc sporo tych miejsc jest.

Jak to można rozwiązać żeby to trzymało się kupy i żeby nie tworzyć kosmicznych ilości tych metod w repo?

W laravelu przy innym zalozeniu ORM mozna zrobic cos takiego $encja->notCancelled()->where([...]);

Czy w doctrine tez daloby sie dodac taki jakby filtr? Chcialbym po prostu miec latwy sposob na to, by zrobic normalne findBy i findOneBy ale biorac tylko encje z dateCancelled IS NULL.

Macie jakies pomysly jak to ogarnąć? Pomyślałem o przepisaniu metody findBy w sposób bardziej laravelowy, by dac tam jeszcze operatory porownania, ale gdy zacząłem to robic okazało się, że napisałbym do tego pewnie więcej kodu niż metod w repo. Dodatkowo, przy takiej operacji ciężko przewidzieć jakie to może mieć negatywne skutki.

#doctrine #symfony #pytanie #programowanie

[ghost1511]

@spike200: Brzmi jak bardzo silne sprzężenie Doctrine z kodem aplikacji. Powinieneś repozytorium doctrine przekazać przez Dependency Injection do własnej klasy repozytorium, a tam wyprowadzić metodę która będzie zwracała odpowiednie dane, np findNotCancelledOrders. Dzięki temu kolejne zmiany będą mniej bolesne, bo wszystkie metody będziesz miał w swoim repo i niejako nie wiążesz na sztywno swojego kodu z Doctrine.

[M.....k]

Problem zaczyna się w kodzie, jest sporo miejsc, gdzie użyty jest zwykły findBy oraz findOneBy. Nie wspierają one jednak IS NULL czy IS NOT NULL i nie ma szans sprawdzić czy encja jest cancelled czy nie jeśli polem jest data.

@spike200: Na przyszłość zrób swoją własną klasę repozytorium w której trzymasz wszystkie zapytania. Gdybyś tak zrobił to uniknąłbyś tego problemu.

Czy w doctrine tez daloby sie dodac taki jakby filtr?

https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/filters.html

[spike200]

@ghost1511: @MDobak: Obaj macie rację ale ten projekt jest bardzo stary, ma z 6 lat a pracuje przy nim od 2. Nie miałem wpływu jak to wygląda, wiec nie ma co płakać tylko trza znaleźć rozwiązanie ;) Refactoring to czesc sprzątania tego kodu, więc staram się znaleźć jakieś zmyślne rozwiązanie na to. Nie mogę jednak przenieść rozrzuconych SQL z kontrolerów i metod findBy zamienić na metody z repo, ponieważ nikt

[ghost1511]

@spike200: To najprostsza i najłatwiejsza opcja w przypadku refactoringu, i tak musisz zmienić kod we wszystkich przypadkach, więc przerzucenie tego do osobnej klasy wygeneruje najmniej strat czasowych. Możesz też nie zmieniać typu kolumny i dodać drugą z informacją o dacie.

[spike200]

@ghost1511: No chyba to po prostu przeniose do repo, wszystkiego nie, ale akurat te czesc. W sumie moge to w miare skategoryzowac i dodac pare argumentow i powinno to pokryc wiekszosc rzeczy.

Co do wywalania tego pola, to w sumie sam nie wiem po co to robic. Bylo to zaplanowane z góry, ja to mam tylko zrobić, podobno używanie datecancelled zamiast iscancelled jest lepszym standardem. I jak masz ORM