Wycofanie: Doctrine \ ORM \ Mapping \ UnderscoreNamingStrategy bez informowania o tym, że numer jest przestarzały

53

Używam Symfony 4.3.8 i nie mogę znaleźć żadnych informacji na temat tych wycofań:

Przestarzałe przez użytkownika: Tworzenie Doctrine \ ORM \ Mapping \ UnderscoreNamingStrategy bez informowania o tym jest przestarzałe i zostanie usunięte w Doctrine ORM 3.0.

Tworzenie Doctrine \ ORM \ Mapping \ UnderscoreNamingStrategy bez uświadamiania numeru jest przestarzałe i zostanie usunięte w Doctrine ORM 3.0.

Przeszukałem w Stacktrace i znalazłem to:

class UnderscoreNamingStrategy implements NamingStrategy
{
private const DEFAULT_PATTERN      = '/(?<=[a-z])([A-Z])/';
private const NUMBER_AWARE_PATTERN = '/(?<=[a-z0-9])([A-Z])/';

/**
 * Underscore naming strategy construct.
 *
 * @param int $case CASE_LOWER | CASE_UPPER
 */
public function __construct($case = CASE_LOWER, bool $numberAware = false)
{
    if (! $numberAware) {
        @trigger_error(
            'Creating ' . self::class . ' without making it number aware is deprecated and will be removed in Doctrine ORM 3.0.',
            E_USER_DEPRECATED
        );
    }

    $this->case    = $case;
    $this->pattern = $numberAware ? self::NUMBER_AWARE_PATTERN : self::DEFAULT_PATTERN;
}

W tej klasie konstruktor jest zawsze wywoływany bez parametrów, więc $ numberAware jest zawsze fałszywe.

Ta klasa jest wywoływana w pliku, który został automatycznie wygenerowany przez Symfony Dependency Injection, więc nie mogę jej „edytować” ...

Myślałem, że może to jest w doctrine.yaml:

doctrine:
orm:
    auto_generate_proxy_classes: true
    naming_strategy: doctrine.orm.naming_strategy.underscore
    auto_mapping: true
    mappings:
        App:
            is_bundle: false
            type: annotation
            dir: '%kernel.project_dir%/src/Entity'
            prefix: 'App\Entity'
            alias: App

Ale nie znalazłem żadnej opcji, aby pozwolić, by numer był świadomy :(

leobrl
źródło
3
Po prostu stwórz nowy projekt 4.4.0 (właśnie wydany, tak), a doctrine.yaml ma w nim „nazing_strategy: doctrine.orm.naming_strategy.underscore_number_aware”. Spróbuj ulepszyć swój.
Cerad

Odpowiedzi:

111

W większości przypadków po prostu odpowiadam na to pytanie komentarzem, ale podejrzewam, że inni programiści mogą napotkać ten problem. Rozejrzałem się trochę i nie mogłem znaleźć żadnej wyraźnej dokumentacji na ten temat. Być może dlatego, że DoctrineBundle jest pod kontrolą ludzi Doctrine, a nie deweloperów Symfony. A może jestem po prostu złym poszukiwaczem.

W każdym razie między 4.3 a 4.4 nazwa usługi dla strategii nazewnictwa podkreślenia została zmieniona.

# doctrine.yaml
orm:
  # 4.3
  naming_strategy: doctrine.orm.naming_strategy.underscore
  # 4.4
  naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware

Dodano komunikat o deprecjacji, aby ostrzec programistów przed zmianą nazwy. Byłoby miło, gdyby przesłanie było trochę bardziej wyraźne, ale no cóż. Jeśli więc aktualizujesz istniejącą aplikację do wersji 4.4 lub nowszej, prawdopodobnie będziesz musiał ręcznie edytować plik doctrine.yaml, aby komunikat o deprecjacji zniknął.

Więcej informacji (dzięki @janh) na temat tego, dlaczego wprowadzono zmianę: https://github.com/doctrine/orm/blob/2.8.x/UPGRADE.md#deprecated-number-unaware-doctrineormmappingunderscorenamingstrategy https: // github. com / doctrine / orm / Issues / 7855

Nadal nie do końca jasne, dlaczego „wybrali” robić to w ten sposób, ale no cóż. Prawdopodobnie chcesz uruchomić „bin / console doctrine: schema: update --dump-sql”, aby sprawdzić, czy wpłynie to na nazwy kolumn bazy danych i odpowiednio je dostosuj. Zmiany zostały wprowadzone już od kilku tygodni i wydaje się, że nie ma zbyt wiele wycia oburzenia z powodu zmiany, więc chyba większość nazw kolumn nie ma osadzonych liczb. Przynajmniej jak dotąd.

Cerad
źródło
stara zmiana strategii (niepoprawnie), na przykład $ singleMd5Key na single_payu_md5key i nowa (poprawnie) single_payu_md5_key. ale ponieważ to jest zmiana BC, mamy cały ten bałagan.
Tomek Kobyliński
@ TomekKobyliński Czy udało Ci się znaleźć dokumentację na ten temat oprócz samego kodu? Wciąż staram się zrozumieć, dlaczego konwencja nazewnictwa zmieniłaby się (a zatem prawdopodobnie wymusiłaby zmianę schematu bazy danych), gdy nadejdzie Doctrine 3. Wygląda na to, że oba podejścia byłyby obsługiwane.
Cerad
1
Więc zamiast wymuszać zmianę schematu bazy danych, musisz ręcznie zaktualizować odwzorowania encji? Nie jestem pewien, co jest gorsze i tak naprawdę nie odnosi się do pytania, dlaczego zmiana w ogóle. Nie ma problemu z zapewnieniem bardziej „poprawnej” strategii, ale nadal nie rozumiem, dlaczego pierwotna strategia jest „niewłaściwa” w jakimkolwiek istotnym znaczeniu.
Cerad
1
Przybył tutaj po zanurzeniu się w tę deprecjację (znalezioną przez uruchomienie phpunit). Przydałby
Rvanlaak
1
@Cerad Jest coś w informacjach o aktualizacji doktryny: github.com/doctrine/orm/blob/2.8.x/... Myślę, że github.com/doctrine/orm/issues/7855 jest istotnym problemem.
janh