Doctrine ORM первая сущность, миграции и фикстуры

Оглавление (нажмите, чтобы открыть):

Миграции Symfony Doctrine, как я могу использовать несколько менеджеров сущностей

Используя Symfony 2.5 и Doctrine 2.2, у меня есть несколько баз данных для приложения, над которым я работаю, давайте назовем одну «Основную», а другую «Вторичную». В настоящее время настроены два менеджера сущностей. В одной миграции я хочу создать таблицу в «Secondary», но она хочет создать таблицу только в «Main».

Миграция может быть ContainerAware, поэтому я могу получить другой EntityManager, но мне не удалось переопределить стандартное. Кто-нибудь может помочь? Заранее спасибо!

Решение

Просто пройдите —em параметр при генерации diff ,

Чтобы исключить пользовательские таблицы из удаления, используйте:

согласно этот документ, в качестве альтернативы вы можете передать аргумент фильтра во время выполнения:

Вопрос по mysql, orm, doctrine-orm, symfony, php &#8211 Как я могу получить сущность из справочника Doctrine Fixture?

Я добавил в свой проект данные, которые основаны на ссылках на объекты сущностей друг от друга.

В первом приборе данных я добавил ссылки на сущности, такие как:

Где $ groupAdmin и $ groupUser являются объектами Group (). Во втором файле фикстур я хочу добавить эти сущности в мою сущность пользователя с помощью:

$ userActive — это объект пользователя с отношением «многие ко многим» к объекту группы. К сожалению, кажется, что я передаю только прокси-объект сущности, а не саму сущность, которая выдает следующую ошибку:

Как мне преобразовать ссылку из прокси в объект, который он ожидает?

Generating Migrations

Doctrine can generate blank migrations for you to modify or it can generate functional migrations for you by comparing the current state of your database schema to your mapping information.

Generating Blank Migrations

To generate a blank migration you can use the generate command:

Diffing Using the ORM

If you are using the ORM, you can modify your mapping information and have Doctrine generate a migration for you by comparing the current state of your database schema to the mapping information that is defined by using the ORM. To test this functionality, create a new User entity located at lib/MyProject/Entities/User.php .

Now when you run the diff command it will generate a migration which will create the users table:

Take a look at the generated migration:

Notice how the table named example_table that we created earlier in the Managing Migrations chapter is being dropped. This is because the table is not mapped anywhere in the Doctrine ORM and the diff command detects that and generates the SQL to drop the table. If you want to ignore some tables in your database take a look at Ignoring Custom Tables chapter.

Now you are ready to execute your diff migration:

The SQL generated here is the exact same SQL that would be executed if you were using the orm:schema-tool command. This just allows you to capture that SQL and maybe tweak it or add to it and trigger the deployment later across multiple database servers.

Diffing Without the ORM

Internally the diff command generates a Doctrine\DBAL\Schema\Schema object from your entities metadata using an implementation of Doctrine\Migrations\Provider\SchemaProviderInterface . To use the Schema representation directly, without the ORM, you must implement this interface yourself.

The SchemaProviderInterface only has one method named createSchema . This should return a Doctrine\DBAL\Schema\Schema instance that represents the state to which you’d like to migrate your database.

The StubSchemaProvider provided with the migrations library is another option. It simply takes a schema object to its constructor and returns it from createSchema .

By default the Doctrine Migrations command line tool will only add the diff command if the ORM is present. Without the ORM, you’ll have to add the diff command to your console application manually, passing in your schema provider implementation to the diff command’s constructor. Take a look at the Custom Integration chapter for information on how to setup a custom console application.

With the custom provider in place the diff command will compare the current database schema to the one provided by the SchemaProviderInterface implementation. If there is a mismatch, the differences will be included in the generated migration just like the ORM examples above.

Formatted SQL

You can optionally pass the —formatted option if you want the dumped SQL to be formatted. This option uses the jdorn/sql-formatter package so you will need to install this package for it to work:

Ignoring Custom Tables

If you have custom tables which are not managed by Doctrine you will need to tell Doctrine to ignore these tables. Otherwise, everytime you run the diff command, Doctrine will try to drop those tables. You can configure Doctrine with a schema filter.

With this expression all tables prefixed with t will ignored by the schema tool.

If you use the DoctrineBundle with Symfony you can set the schema_filter option in your configuration. You can find more information in the documentation of the DoctrineMigrationsBundle.

Doctrine ORM: первая сущность, миграции и фикстуры

Проект Doctrine состоит из нескольких библиотек (компонентов). Каждый компонент Doctrine распространяется как пакет для установки Composer’ом и зарегистрирован в каталоге Packagist.org. Похожий метод использует Zend Framework 3 для установки своих компонентов.

Ниже мы предоставим краткое описание архитектуры библиотеки Doctrine, чтобы дать вам общее представление о ее возможностях.

Мастер Йода рекомендует:  Алгоритмы и структуры данных для начинающих динамический массив

Компоненты, поддерживающие реляционные базы данных

Основные компоненты Doctrine предназначены для работы с реляционными БД и показаны на рисунке Г.2 (помечены зеленым). Голубые блоки обозначают PHP-движок и расширения PHP, на основе которых построена Doctrine.

Рисунок Г.2. Компоненты Doctrine, предназначенные для работы с реляционными БД

Как видно из рисунка, Doctrine основана на свойствах PHP-движка и расширениях PHP, которых обычно используются как драйвера к определенным системам управления БД. Над этим базовым уровнем находятся ключевые компоненты Doctrine (такие как Annotations , Common и т.д), обеспечивающие необходимую функциональность для других компонентов верхнего уровня. Компонент DBAL предоставляет абстрактный уровень типа БД. На самом верхнем уровне находится компонент ORM , предоставляющий API для работы с данными объектно-ориентированным методом. Компоненты DoctrineModule and DoctrineORMModule` предназначены для интеграции с Zend Framework 3.

Компонент ORM использует паттерн Data Mapper (преобразователь данных). Этот паттерн указывает на то, что таблица базы данных может быть представлена как PHP-класс сущности. База данных в этом паттерне считается чем-то вроде репозитория (хранилищем сущностей). Когда вы извлекаете сущность из репозитория, выполняется внутренний SQL-запрос и создается класс сущности, чьи свойства заполняются данными.

По аналогии с компонентами ZF3, имена компонентов Doctrine состоят из двух частей: имени поставщика («Doctrine») и имени компонента (например, «Common»). Ниже представлен список компонентов Doctrine вместе с именами их пакетов, устанавливаемыми Composer’ом, и краткими описаниями:

Doctrine\Common . Общая библиотека для проектов Doctrine. Этот компонент предоставляет широко используемый набор функций. Имя пакета, устанавливаемого Composer’ом — doctrine/common .

Doctrine\Annotations . Парсер многострочных комментариев. Имя пакета, устанавливаемого Composer’ом — doctrine/annotations .

Doctrine\Inflector . Манипуляции со строками, касающиеся изменения регистра и единственного/множественного числа. Имя пакета, устанавливаемого Composer’ом — doctrine/inflector .

Doctrine\Lexer . Базовая библиотека для лексического анализатора, который может использоваться в нисходящем синтаксическом анализе и методе рекурсивного спуска. Имя пакета, устанавливаемого Composer’ом — doctrine/lexer .

Doctrine\Cache . Библиотека для кэширования, предлагающая объектно-ориентированный API для многих бэкендов кеша. Имя пакета, устанавливаемого Composer’ом — doctrine/cache .

Doctrine\DBAL . Абстрактный уровень БД. This is a lightweight and thin runtime layer around a PDO-like API and a lot of additional, horizontal features like database schema introspection and manipulation through an object oriented API. Имя пакета, устанавливаемого Composer’ом — doctrine/dbal .

Doctrine\Collections . Библиотека для абстракции коллекций. Имя пакета, устанавливаемого Composer’ом — doctrine/collections .

Doctrine\ORM . Компонент для объектно-реляционного отображения. Позволяет работать с моделями сущностей объектно-ориентированным методом вместо запросов на чистом SQL. Имя пакета, устанавливаемого Composer’ом — doctrine/orm .

Doctrine\Migrations . Миграции схем БД с использованием Doctrine DBAL. Предоставляет последовательный способ управления схемой БД и ее обновления. Имя пакета, устанавливаемого Composer’ом — doctrine/migrations .

Doctrine\DataFixtures . Данные предварительной настройки для всех менеджеров объектов Doctrine. Предоставляет фреймворк для создания данных предварительной настройки. Имя пакета, устанавливаемого Composer’ом — doctrine/data-fixtures .

Так как Doctrine использует автозагрузку PHP, а также стандарт PSR-4, классы, принадлежащие определенному компоненту, «живут» в пространстве имен этого компонента. Например, класс EntityManager , принадлежащий компоненту Doctrine\ORM , живет в пространстве имен Doctrine\ORM .

Компоненты, поддерживающие документоориентированные NoSQL-БД

Компоненты Doctrine, предназначенные для работы с NoSQL-базами (MongoDB, CouchDB и т.д.) показаны на рисунке Г.3 и отмечены зеленым. Голубые блоки обозначают PHP-движок и расширения PHP, на основе которых построена Doctrine.

Рисунок Г.3. Компоненты Doctrine, предназначенные для работы с документо-ориентированными БД

Как видно из рисунка Г.3, компоненты Doctrine для NoSQL-БД основаны на свойствах PHP-движка и расширениях PHP, которые можно считать «драйверами» для определенных систем управления базами данных. Выше находятся компоненты среднего уровня. Компонент Common — тот же самый, что был показан на рисунке Г.2; он представляет широко используемый набор функций. Компоненты Mongodb и CouchDB предоставляют низкоуровневые API соответствующим базам данных. Компоненты MongodbODM , CouchdbODBM , OrientdbODM и PhpcrODM предоставляют ODM (Object Document Mappers) для соответствующих БД. Концепция ODM очень похожа на ORM тем, что тоже предоставляет возможность работать с NoSQL-БД объектно-ориентированным методом, устанавливая соответствие между документами и моделями сущностей PHP. Компонент DoctrineMongoODMModule предназначен для интеграции с ZF3.

Ниже представлен список компонентов вместе с именами их пакетов, устанавливаемыми Composer’ом, и краткими описаниями:

Doctrine\MongoDB — уровень абстракции Dotrine MongoDB. Имя пакета, устанавливаемого Composer’ом — doctrine/mongodb .

Doctrine\MongodbODM (Object Document Mapper) предоставляет возможность устанавливать соответствие между документами NoSQL и моделями сущностей PHP. Имя пакета, устанавливаемого Composer’ом — doctrine/mongodb-odm .

Doctrine\MongoODMModule — модуль Zend Framework 3, обеспечивающий функциональность Doctrine MongoDB ODM. Он служит для простой интеграции с ZF3. Имя пакета, устанавливаемого Composer’ом — doctrine/doctrine-mongo-odm-module .

Doctrine\CouchDB — компонент, предоставляющий API, который является оберткой для API CouchDB для доступа по HTTP. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

Doctrine\CouchDB — компонент CouchDB Document Object Mapper. Аналогично Doctrine ORM он предоставляет возможность доступа к БД объектно-ориентированным методом. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

Doctrine\OrientdbODM — набор библиотек PHP для использования OrientDB. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

Doctrine\PhpcrODM — это Object Document Mapper для PHPCR. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

[Doctrine] BEST PRACTICES — 1

Замечательный человек Marco Pivetta, который больше известен под ником Ocramius и который участвует в развитии Doctrine ORM, составил презентацию, в которой описал лучшие практики, которых следует придерживаться при работе с Doctrine.

На официальном сайте Doctrine так же присутствует раздел, под названием Best practices , но он очень мал.

1. Общие правила.

Как правильно при первом знакомстве с Doctrine все сущности, которые мы создаем являются по сути обычными POCO объектами , которые на каждое свойство имеют по get\set методу и не имеют конкретного поведения.

«Сущности должны работать без ORM», означает то, что вы должны абстрагировать ваши сущности от логики ORM, т.е. если вы вдруг захотите сменить Doctrine на Propel, вам не пришлось бы менять код в бизнес-логике. Однако тут возникают ограничения, накладываемые ORM, например коллекции в Doctrine — «ArrayCollection» которые используются внутри сущностей, для работы со связями.

«Сущности должны работать без БД» — пункт, который в принципе и так исполняем, так как вся логика работы с БД у нас инкапсулируется в самой ORM. Исключение составляет разве, что Active Record сущности с sql внутри.

«Сущности являются отображением доменной логики вашего приложения» — доменная логика — это часть подхода в DDD методологии, сформулированной Эвансом. Соответственно, ваши сущности не должны быть пустыми болванками, с двумя методами на свойство. Ваши сущности, в первую очередь, должны обладать поведением.

Мастер Йода рекомендует:  Qeexo анонсировала технологию определения угла касания для сенсорных экранов

При проектировании вашего приложения, рекомендуется пользоваться code-first подходом, когда вы сперва проектируете ваши сущности и взаимодействие между ними, а после уже занимаетесь проектированием хранилища и тем, каким образом помещать в него данные. В ходе работы может появиться необходимость в нескольких базах данных, или в разделении хранилищ с хранением различных кусков данных единой сущности. В итоге ваши сущности не должно волновать, каким образом вы организуете персистентный слой, ваши сущности должны быть заняты бизнес логикой приложения.

2. Придайте Entity осмысленности.

При таком подходе наша Entity напоминает больше ассоциативный массив, нежели полноценный объект. Чтобы решить эту проблему, данному классу нужно придать немного больше информативности:

Таким образом мы придали сущности более осмысленное, в рамках доменной логики, поведение, а так же защитили его от неконтролируемых изменений. Начинайте проектировать свои сущности на уровне интерфейса, так вы сможете абстрагироваться от детализации и сосредоточиться над общей структурой ваших сущностей и их взаимодействия.

3. Инкапсулируйте взаимодействие с коллекцией внутри Entity.

Если ваша сущность имеет внутри себя коллекцию зависимых объектов, с которыми вы хотите работать, то лучшим образом это будет делать через сам класс сущности, вместо того, чтобы выносить коллекции из сущности куда-то еще.

Такой подход является следствием создания сущностей-болванок, по этому оптимальным вариантом будет некоторые операции размещать внутри методов самой сущности. В данном случае — CRUD операции с коллекциями.

Конечно в простых примерах взаимодействие с коллекциями кажется таким же простым. Однако в реальном приложении на сцену выходит множество факторов и внешних зависимостей, и данную логику часто приходится размещать, как раз-таки, во внешних сервисах бизнес уровня приложения.

4.Ваши сущности всегда должны находится в валидном состоянии.

Как касательно самих типов данных, чтобы в поле для целого значения не прилетела строка, например, так и касательно самих бизнес-правил, чтобы email был валидным, а пароль не меньше 3 и т.д. Вы должны всегда доверять сущности и быть в ней уверены. Однако не следует помещать в методы сущности комплексные валидационные правила, которые работают с данными пользователя. У вас всегда должны быть слои взаимодействия. Валидацию самой пользовательской формы отдавайте валидаторам — это может быть сервис, или input-фильтры, как в ZF2, или формы, как в SF2, или любые другие инструменты.

Это правильно тоже касается валидации. Ваши сущности не должны существовать без жизненноважных зависимостей. Например: профиль пользователя не может существовать без самого пользователя, по этому нужно запретить создание профиля, без передачи ему в конструктор сущности User. Если посмотреть с другой стороны, то очевидно, что при создании пользователя желательно создавать и профиль для него, это можно сделать в конструкторе сущности User, тем самым обеспечить их связь на этапе создания, без лишних телодвижений с сеттерами и проверками на существование.

6. Не рекомендуется использовать классы из уровня выше, в классах, уровня ниже.

Т.е. не желательно использовать в сущностях — сервисы, репозитории и другие классы, которые для своей работы сами используют сущности и соответственно находятся уровнем выше над ними.

symfony3 Doctrine — Миграции

Primary tabs

Forums:

Установим пакет

и подключаем пакет в AppKernel.php :

а также добавляем настройки в config.yml :

Подготовка окончена, можем приступать к работе.

Команды миграций

Переходим в терминале в папку с нашим проектом и вводим команду

php bin/console doctrine:migrations *а далее один из вариантов ниже

  • :diff — создаёт миграцию для сравнения Вашей схемы со схемой в базе данных. При выполнении данной миграции оба варианта будут приведены
  • :execute — применяет конкретную миграцию, нужно указать её номер:

php bin/console doctrine:migrations:execute 20200925141401

php bin/console doctrine:migrations:version 20200925141401 —add

php bin/console doctrine:migrations:version 20200925141401 —delete

Symfony4

В Symfony 4 создание миграции происходит с помощью команды:

Данная команда одновременно создаёт класс миграции, определяет различия между БД и структурой сущностей и сразу добавляет в класс код, удаляющий эти различия.

Как написать миграцию Doctrine, которая может перераспределять данные в новые таблицы

У меня есть база данных (которая была создана с использованием Propel в приложении Symfony1). Я переоцениваю его в Symfony2 и Doctrine, но я также хочу воспользоваться возможностью для реорганизации базы данных.

Я определил набор Doctrine Entities и запустил doctrine: migrations: diff, который создал мне базовую миграцию для добавления таблиц, столбцов и ограничений и сбросил нагрузку на столбцы.

Однако перед удалением этих столбцов я хочу скопировать данные в некоторые из новых таблиц, а затем связать новые записи в этой таблице с новыми столбцами в первой таблице. Я не думаю, что это можно сделать в чистом SQL (в общем, содержимое одной таблицы распределяется между тремя или четырьмя таблицами).

Это дал мне подсказку и заставил меня найти this ( который я пропустил, потому что я понятия не имел, какая релевантность «контейнеров» может быть для моей проблемы).

Но то, что я не нашел нигде в документации по Symfony или Doctrine, является примером фактического перемещения данных во время миграции, что для меня, по-видимому, является одной из основных целей миграции!

Возможно, что я мог использовать подсказки в этих ссылках выше, но тогда я не уверен, как действовать дальше. У меня нет (и на самом деле не хочу тратить время на создание, хотя я уверен, что могу это сделать) Объекты Doctrine для существующей схемы базы данных: могу ли я затем использовать DQL? Я просто не знаю.

Итак, два вопроса:

Может ли кто-нибудь дать мне пример миграции Doctrine, которая перемещает данные между таблицами?

В качестве альтернативы, может ли кто-нибудь выяснить, насколько зависим синтаксис DQL от определений сущностей в доктрине? Могу ли я использовать его для указания столбцов, которые не указаны в определениях Entity?

Please verify you are a human

Access to this page has been denied because we believe you are using automation tools to browse the website.

This may happen as a result of the following:

  • Javascript is disabled or blocked by an extension (ad blockers for example)
  • Your browser does not support cookies

Please make sure that Javascript and cookies are enabled on your browser and that you are not blocking them from loading.

Мастер Йода рекомендует:  Изучаем Angular текстовые туториалы

Reference ID: #66dc48b0-03e8-11ea-9e8d-edc7d3bef341

Doctrine ORM: первая сущность, миграции и фикстуры

Проект Doctrine состоит из нескольких библиотек (компонентов). Каждый компонент Doctrine распространяется как пакет для установки Composer’ом и зарегистрирован в каталоге Packagist.org. Похожий метод использует Zend Framework 3 для установки своих компонентов.

Ниже мы предоставим краткое описание архитектуры библиотеки Doctrine, чтобы дать вам общее представление о ее возможностях.

Компоненты, поддерживающие реляционные базы данных

Основные компоненты Doctrine предназначены для работы с реляционными БД и показаны на рисунке Г.2 (помечены зеленым). Голубые блоки обозначают PHP-движок и расширения PHP, на основе которых построена Doctrine.

Рисунок Г.2. Компоненты Doctrine, предназначенные для работы с реляционными БД

Как видно из рисунка, Doctrine основана на свойствах PHP-движка и расширениях PHP, которых обычно используются как драйвера к определенным системам управления БД. Над этим базовым уровнем находятся ключевые компоненты Doctrine (такие как Annotations , Common и т.д), обеспечивающие необходимую функциональность для других компонентов верхнего уровня. Компонент DBAL предоставляет абстрактный уровень типа БД. На самом верхнем уровне находится компонент ORM , предоставляющий API для работы с данными объектно-ориентированным методом. Компоненты DoctrineModule and DoctrineORMModule` предназначены для интеграции с Zend Framework 3.

Компонент ORM использует паттерн Data Mapper (преобразователь данных). Этот паттерн указывает на то, что таблица базы данных может быть представлена как PHP-класс сущности. База данных в этом паттерне считается чем-то вроде репозитория (хранилищем сущностей). Когда вы извлекаете сущность из репозитория, выполняется внутренний SQL-запрос и создается класс сущности, чьи свойства заполняются данными.

По аналогии с компонентами ZF3, имена компонентов Doctrine состоят из двух частей: имени поставщика («Doctrine») и имени компонента (например, «Common»). Ниже представлен список компонентов Doctrine вместе с именами их пакетов, устанавливаемыми Composer’ом, и краткими описаниями:

Doctrine\Common . Общая библиотека для проектов Doctrine. Этот компонент предоставляет широко используемый набор функций. Имя пакета, устанавливаемого Composer’ом — doctrine/common .

Doctrine\Annotations . Парсер многострочных комментариев. Имя пакета, устанавливаемого Composer’ом — doctrine/annotations .

Doctrine\Inflector . Манипуляции со строками, касающиеся изменения регистра и единственного/множественного числа. Имя пакета, устанавливаемого Composer’ом — doctrine/inflector .

Doctrine\Lexer . Базовая библиотека для лексического анализатора, который может использоваться в нисходящем синтаксическом анализе и методе рекурсивного спуска. Имя пакета, устанавливаемого Composer’ом — doctrine/lexer .

Doctrine\Cache . Библиотека для кэширования, предлагающая объектно-ориентированный API для многих бэкендов кеша. Имя пакета, устанавливаемого Composer’ом — doctrine/cache .

Doctrine\DBAL . Абстрактный уровень БД. This is a lightweight and thin runtime layer around a PDO-like API and a lot of additional, horizontal features like database schema introspection and manipulation through an object oriented API. Имя пакета, устанавливаемого Composer’ом — doctrine/dbal .

Doctrine\Collections . Библиотека для абстракции коллекций. Имя пакета, устанавливаемого Composer’ом — doctrine/collections .

Doctrine\ORM . Компонент для объектно-реляционного отображения. Позволяет работать с моделями сущностей объектно-ориентированным методом вместо запросов на чистом SQL. Имя пакета, устанавливаемого Composer’ом — doctrine/orm .

Doctrine\Migrations . Миграции схем БД с использованием Doctrine DBAL. Предоставляет последовательный способ управления схемой БД и ее обновления. Имя пакета, устанавливаемого Composer’ом — doctrine/migrations .

Doctrine\DataFixtures . Данные предварительной настройки для всех менеджеров объектов Doctrine. Предоставляет фреймворк для создания данных предварительной настройки. Имя пакета, устанавливаемого Composer’ом — doctrine/data-fixtures .

Так как Doctrine использует автозагрузку PHP, а также стандарт PSR-4, классы, принадлежащие определенному компоненту, «живут» в пространстве имен этого компонента. Например, класс EntityManager , принадлежащий компоненту Doctrine\ORM , живет в пространстве имен Doctrine\ORM .

Компоненты, поддерживающие документоориентированные NoSQL-БД

Компоненты Doctrine, предназначенные для работы с NoSQL-базами (MongoDB, CouchDB и т.д.) показаны на рисунке Г.3 и отмечены зеленым. Голубые блоки обозначают PHP-движок и расширения PHP, на основе которых построена Doctrine.

Рисунок Г.3. Компоненты Doctrine, предназначенные для работы с документо-ориентированными БД

Как видно из рисунка Г.3, компоненты Doctrine для NoSQL-БД основаны на свойствах PHP-движка и расширениях PHP, которые можно считать «драйверами» для определенных систем управления базами данных. Выше находятся компоненты среднего уровня. Компонент Common — тот же самый, что был показан на рисунке Г.2; он представляет широко используемый набор функций. Компоненты Mongodb и CouchDB предоставляют низкоуровневые API соответствующим базам данных. Компоненты MongodbODM , CouchdbODBM , OrientdbODM и PhpcrODM предоставляют ODM (Object Document Mappers) для соответствующих БД. Концепция ODM очень похожа на ORM тем, что тоже предоставляет возможность работать с NoSQL-БД объектно-ориентированным методом, устанавливая соответствие между документами и моделями сущностей PHP. Компонент DoctrineMongoODMModule предназначен для интеграции с ZF3.

Ниже представлен список компонентов вместе с именами их пакетов, устанавливаемыми Composer’ом, и краткими описаниями:

Doctrine\MongoDB — уровень абстракции Dotrine MongoDB. Имя пакета, устанавливаемого Composer’ом — doctrine/mongodb .

Doctrine\MongodbODM (Object Document Mapper) предоставляет возможность устанавливать соответствие между документами NoSQL и моделями сущностей PHP. Имя пакета, устанавливаемого Composer’ом — doctrine/mongodb-odm .

Doctrine\MongoODMModule — модуль Zend Framework 3, обеспечивающий функциональность Doctrine MongoDB ODM. Он служит для простой интеграции с ZF3. Имя пакета, устанавливаемого Composer’ом — doctrine/doctrine-mongo-odm-module .

Doctrine\CouchDB — компонент, предоставляющий API, который является оберткой для API CouchDB для доступа по HTTP. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

Doctrine\CouchDB — компонент CouchDB Document Object Mapper. Аналогично Doctrine ORM он предоставляет возможность доступа к БД объектно-ориентированным методом. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

Doctrine\OrientdbODM — набор библиотек PHP для использования OrientDB. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

Doctrine\PhpcrODM — это Object Document Mapper для PHPCR. Имя пакета, устанавливаемого Composer’ом — doctrine/couchdb .

Doctrine Migrations and Fixtures: Загрузка сущностей во время миграции из фикстура

У меня есть сайт, который успешно использует как Doctrine Migrations, так и Fixtures (удивительные функции!), однако у меня небольшая проблема.

Я добавил таблицу и новое поле внешнего ключа в эту таблицу в существующем объекте. Миграция заполняет новую таблицу с ее начальными значениями.

В моем устройстве, которое загружает данные для таблицы с внешним ключом, мне нужно установить поле в одно из значений, созданных в процессе переноса, но я не могу получить никаких объектов из этого репозитория.

Любые идеи, почему это происходит, или предложение о том, как я должен делать это по-другому.

Инструмент реализует ContainerAwareInterface , так что у меня есть доступ к репозиторию объектов, но выполните:

ничего не возвращает, хотя я вижу, что в этой точке есть значения в БД.

Добавить комментарий