Symfony2: объект воссоздан после переименования

Я создал пакет Super и создал относительную сущность "sin_table1.php" как генерацию таблицы mysql "sin_table1".

После:

 php app/console doctrine:generate:entities AcmeSuperBundle

а также

  php app/console doctrine:schema:update --force

Теперь я вижу полную сгенерированную таблицу mysql.

Но если я переименую sin_table1.php в другое имя как «mysql_schema.php» и попытаюсь перезагрузить эти команды, doctrine/symfony2 воссоздает файл Entity «sin_table1.php».

Я попытался найти ключ "sin_table1" в корневом проекте symfony2, но ничего не нашел. Только кеши, журналы и два файла Entitiy (sin_table1.php и mysql_schema.php).

Я пытался очистить кеш, но ничего не произошло, всегда заново создается sin_table1.php и конфликтует с mysql_schema.php, потому что есть двойное декарирование одного и того же класса.

Как я могу это решить? где в доктрине сохранена конфигурация объекта sin_table1? почему это происходит?

я думаю, что я потерял что-то, читая руководство....


php symfony entity doctrine-orm
person B33th0v3n    schedule 18.03.2014    source источник
comment
Можете ли вы добавить больше кода, пожалуйста? Ваша сущность использует аннотацию? Возможно, у вас есть @Table(name=sin_table1).   -  person Debflav    schedule 18.03.2014
comment
Это мои первые эксперименты с symfony и доктриной, и после очередного теста я думаю, что имя файла должно совпадать с содержащимся в нем классом. Это моя гипотеза/предположение, но я не уверен.   -  person B33th0v3n    schedule 18.03.2014

Ответы (2)


arrow_upward
0
arrow_downward

Файл имени: mysql_schema.php

namespace Acme\SuperBundle\Entity;`
 use Doctrine\ORM\Mapping as ORM;`
    /**`
     * @ORM\Entity`
     * @ORM\Table(name="sin_table1")`
     */`
    class sin_table1`
    {....`

В моем новом тесте я переименовал класс как "sin_tablerrrrrrrrrr", а также @ORM\Table(name="sin_tablerrrrrrrrrr"....

и результатом будет другой созданный файл sin_tablerrrrrrrrrr.php

Если мое предположение, что файл имен должен быть таким же, как у класса, я мог бы быть подписан как решенный.

person B33th0v3n    schedule 18.03.2014

arrow_upward
0
arrow_downward

  • Я всегда устанавливал имя своего класса, идентичное имени моего файла php. Я предполагаю, что это скорее соглашение/лучшая практика разработчиков, чем обязательство.

  • Во всяком случае, несколько недель назад у меня возникла та же проблема, и я увидел, что команда php app/console doctrine:schema:drop не удаляет переименованную таблицу. Таблица со старым именем не была удалена командой. Поэтому, когда я обновился, у меня были обе таблицы. Возможно, это была твоя проблема.

person Debflav    schedule 19.03.2014
comment
да, я понял соглашение о разработке... Эта ситуация произошла со мной, потому что мне нужно создать две пары классов, один для запросов к mysql, а другой для запросов к базе данных elasticsearch. Это связано с тем, что ежедневные журналы будут записываться и удаляться в таблице mysql (как ежедневный кеш), а перед очисткой данных mysql данные должны быть скопированы в базу данных elasticsearch. Поэтому мне нужно сделать 2 класса, работающих в параллельной системе для извлечения одних и тех же данных. Файл имени предназначался только для понимания объекта подключения к данным mysql. Делать нечего, я обязан, мне нужно привыкнуть ^_^ - person B33th0v3n; 19.03.2014
comment
Я не уверен, что понимаю, но если вы хотите создать две таблицы для управления журналами, я предлагаю вам установить планировщик событий в MySQL для сохранения данных, а затем удалить старые данные. Кроме того, вы можете запустить команду с помощью задачи cron. Странно иметь для этого два стола, но, возможно, у вас нет выбора. Желаю вам всяческих успехов в будущем. - person Debflav; 19.03.2014
comment
уверен, что хорошо знаю задачу cron и mysql. Но мне не нужны 2 таблицы в mysql, а одна в mysql и вторая в базе данных elasticsearch. Я использую эластичный поиск, потому что mysql очень хорош для небольших данных, но запросы в гигантской базе данных слишком медленные. База данных Elasticsearch очень отличается, она может очень быстро выдавать результаты в гигантской базе данных. Как вы знаете, журналы — это очень массивные данные, и mysql не может их поддерживать или быть быстрым. Поэтому я использую только mysql для ежедневных журналов, после того как данные будут вставлены в эластичный поиск с помощью cron, как вы понимаете. Посмотрите это: elasticsearch.org - person B33th0v3n; 19.03.2014