„Klasa XXX nie jest prawidłową jednostką lub mapowaną superklasą” po przeniesieniu klasy w systemie plików

Miałem klasę encji w Aib \ PlatformBundle \ Entity \ User.php

Nie miałem problemów z utworzeniem jego klasy formularza za pomocą

php app / console doctrine: generation: form AibPlatformBundle: User

Teraz zmieniłem przestrzeń nazw na Aib \ PlatformBundle \ Entity \ Identity \ User, ale kiedy próbuję wygenerować formularz z zadaniem, które powiedziałem wcześniej, mówi:

„Class Aib \ PlatformBundle \ Entity \ User nie jest prawidłową jednostką lub zmapowaną superklasą”.

Oto zawartość pliku:

<?php
namespace Aib\PlatformBundle\Entity\Identity;

use Doctrine\ORM\Mapping as ORM;

    /**
     * Aib\PlatformBundle\Entity\Identity\User
     *
     * @ORM\Table()
     * @ORM\Entity(repositoryClass="Aib\PlatformBundle\Entity\Identity
    \UserRepository")
     */
    class User
    {
    ...

Dowolny pomysł?

symfony2.0.4

Miałem problem - nie zapomnij o adnotacji * @ORM\Entityjak poniżej:

/**
 * Powma\ServiceBundle\Entity\User
 *
 * @ORM\Entity
 * @ORM\Table(name="users")
 */

Miałem wczoraj ten problem i znalazłem ten wątek. Utworzyłem jednostkę z mapowaniem w nowym pakiecie (np. MyFooBundle / Entity / User.php), wykonałem całą konfigurację zgodnie z dokumentacją, ale podczas próby załadowania aplikacji otrzymałem ten sam błąd z góry.

W końcu zdałem sobie sprawę, że nie ładowałem MyFooBundle w AppKernel:

new My\FooBundle\MyFooBundle()

Świetnym sposobem na debugowanie tego jest uruchomienie tego polecenia:

app/console doctrine:mapping:info

Sprawdź, czy plik config.yml powinien zawierać coś takiego:

# Doctrine Configuration
doctrine:
    dbal:
        driver:   %database_driver%
        host:     %database_host%
        port:     %database_port%
        dbname:   %database_name%
        user:     %database_user%
        password: %database_password%
        charset:  UTF8
        types:
            json: Sonata\Doctrine\Types\JsonType

    orm:
        auto_generate_proxy_classes: %kernel.debug%
        # auto_mapping: true
        entity_managers:
            default:
                mappings:
                    FOSUserBundle: ~
                    # ApplicationSonataUserBundle: ~
                    YourUserBundle: ~
                    SonataUserBundle: ~

Dodaj swój własny pakiet do listy mapowań.

Rozwiązałem to, przekazując falsejako drugi parametr do Doctrine\ORM\Configuration::newDefaultAnnotationDriver.

Zajęło mi trochę czasu przekopanie się przez Google i kod źródłowy.

Mój przypadek był w pewnym sensie wyjątkowy, ponieważ używałem mapowania wskazującego na inny katalog niezwiązany z instalacją Symfony, ponieważ musiałem również użyć starszego kodu.

Zrefaktoryzowałem starsze jednostki i przestały działać. Kiedyś używali @Annotationzamiast @ORM\Annotation, więc po refaktoryzacji po prostu nie udało się odczytać metadanych. Nie używając prostego czytnika adnotacji, wszystko wydaje się być w porządku.

W moim przypadku problem został rozwiązany poprzez zmianę cache moich serwerów z eAccelerator na APC . Najwyraźniej eAccelerator usuwa wszystkie komentarze z plików, co psuje twoje adnotacje.

Rozwiązałem ten problem, ustawiając $useSimpleAnnotationReader=falsepodczas tworzenia MetaDataConfiguration.

wielkie dzięki dla Marka Fu i mogomana

Wiedziałem, że musi to być gdzieś w config.yml ... i móc przetestować to z

app/console doctrine:mapping:info

naprawdę pomogło!

W rzeczywistości to polecenie po prostu zatrzymuje się na błędzie ... bez informacji zwrotnej, ale kiedy wszystko jest w porządku, powinieneś być w stanie zobaczyć wszystkie swoje jednostki na liście.

Rozwiązałem ten sam wyjątek, usuwając konflikt automatycznie wygenerowany plik orm.php z folderu Resources / config / doctrine; zgodnie z dokumentacją: „Pakiet może akceptować tylko jeden format definicji metadanych. Na przykład nie jest możliwe mieszanie definicji metadanych YAML z opisanymi definicjami klas encji PHP.”

Bardzo duże prawdopodobieństwo, że masz PHP 5.3.16 (Symfony 2.x nie będzie z nim działać). W każdym razie powinieneś załadować stronę kontrolną na http://you.site.name/config.php Jeśli projekt nie działał na serwerze hostingowym, kolejne linie muszą zostać usunięte w "config.php":

if (!in_array(@$_SERVER['REMOTE_ADDR'], array(
    '127.0.0.1',
    '::1',
))) {
    header('HTTP/1.0 403 Forbidden');
    exit('This script is only accessible from localhost.');
}

Powodzenia!

W moim przypadku byłem zbyt gorliwy podczas refaktora i usunąłem plik doktryny yml!

W moim przypadku na Macu używałem src / MainBundle / Resource / Config / Doctrine, oczywiście działało na Macu, ale nie działało na produkcyjnym serwerze Ubuntu. Po zmianie nazwy Config na config i Doctrine na doctrine, pliki mapowania zostały znalezione i zaczęło działać.

Pozbyłem się tego samego komunikatu o błędzie, co w twoim przypadku, używając app / console_dev zamiast po prostu app / console