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
php
symfony
doctrine-orm
ziiweb
źródło
źródło
Odpowiedzi:
Miałem problem - nie zapomnij o adnotacji
* @ORM\Entity
jak poniżej:/** * Powma\ServiceBundle\Entity\User * * @ORM\Entity * @ORM\Table(name="users") */
źródło
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:
źródło
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ń.
źródło
Rozwiązałem to, przekazując
false
jako drugi parametr doDoctrine\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
@Annotation
zamiast@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.źródło
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.
źródło
opcache.save_comments=1
, może jest też takie dla eAccelerator / APC?Rozwiązałem ten problem, ustawiając
$useSimpleAnnotationReader=false
podczas tworzeniaMetaDataConfiguration
.źródło
wielkie dzięki dla Marka Fu i mogomana
Wiedziałem, że musi to być gdzieś w config.yml ... i móc przetestować to z
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.
źródło
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.”
źródło
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!
źródło
W moim przypadku byłem zbyt gorliwy podczas refaktora i usunąłem plik doktryny yml!
źródło
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ć.
źródło
Pozbyłem się tego samego komunikatu o błędzie, co w twoim przypadku, używając app / console_dev zamiast po prostu app / console
źródło