Сергей Протько: просто хорошо бы подошло к oneToOne связям, чтобы постоянно не работать с родительским объектом через сеттер и геттер. Как я понял, это нужно писать свое наследование, грубо говоря.
но ведь Inheritance есть как SingleTable и есть Join. В конечном счете это будут таблицы в БД, вот мне и интересно для каких случаев, какой вариант лучше, хотя бы в общих чертах.
Денис: пробовал, но тип формы entity работает через QueryBuilder с запросами к связанным таблицам, из-за этого ошибки, что объект (например Skill) не является entity. А чтобы стало возможным работать через entity - нужно впихнуть свой ORMQueryBuilderLoader, насколько я понял, но и при этом у типа entity есть метод load() который все равно делает запрос к таблице (а у меня YML) для получения списка entity/ Короче не подходит.
Денис: вы поймите. я уже интересовался вопросом работы с данными из YML файла, но ничего подобного, о чем вы тут писали, не всплывало в обсуждении. Может я что-то неверно понимаю из того, что вы написали, в таком случае был бы признателен, если бы вы скинули ссылку на доку, где есть решение проблемы.
Денис: что означает поле SET: я в курсе, вы не поверите. Но я работаю не со строками , мне нужны объекты на выходе, при чем объекты разные, тут не только skills , но и другие данные. И при записи я передаю объекты. Динамика в том, что в поле SET список ,соответствующий данным в YML файле.
Как вам такая система :
Таблица транзакции (где будет хранится основная информация) :
id
sender_id (null || user)
recepient_id (null || user)
amount (0.00)
created_at (DateTime)
updated_at (DateTime)
active (1 || 0)
---------- для вычисления баланса пользователя достаточно будет сложить суммы где он получатель и отнять, где отправитель
========
И другие таблицы могут расширять основную, т.е. таблица для системных и внешних платежей будет хранить :
id
transaction_id
type (BONUS | POINTS | WEBMONEY)
========
Ели нужно внести оплаты за товар, то можно расширить транзакции таблицей:
id
transaction_id
order_id
========
Спасибо за ответ. Но задача заключалась именно в хранении в YML редактировании в YML без взаимодействия с БД. Решено было использовать тип поля SET, создать кастомный тип в Doctrine и связать все через менеджер (сервис). Как-то так.
Сергей Протько: задам уж тут вопрос, так быстрее, создал я тип поля и столкнулся с тем, что в тип-то ничего не заинжектить, а данные о категориях у меня хранятся в контейнере. Как быть ? Неужто не получится ограничится только типом поля и придется фигачить гидратор ? Я глянул ObjectHydrator так чуть не помер от количества всего в нем.
Сергей Протько: глянул. Получается вместо аннотаций, вида "ManyToMany(JoinTable()) и т.д." Просто создать свой тип поля, который будет хранить в себе массив значений ?
Сергей Протько: у меня тут еще вопрос, как система должна реагировать, на случай удаления значение (entity) из yml файла ? При удалении из БД все связи тоже подчищаются, однако же, при удалении из YML все же останется на месте. Я так понимаю, при выборке должна будет идти проверка на соответствие связи - действительности, и если сущность из YML уже не существует, удалять связь ? При использовании ManyToMany будем использовать свою коллекцию, т.е. нужно ее передавать при загрузке приложения в доктрину, чтобы она могла с ней работать ? И по поводу "еще один тип" - тип поля ? Может у вас там где ссылка завалялась на раздел из доков доктрины, как раз для этого случая ? А то ну совсем не понятно, что и в каком порядке нужно делать, каким образом доктрина будет знать, откуда брать данные для связи ManyToMany. Придется править аннотации ?
Сергей Протько: я вроде понял, а вроде и не понял. Ну вот есть у меня 50 записей. Я их закидываю в YML файл:
categories:
category:
id: 1
name: category_1
category:
id: 2
name: category_2
...
- это тупость и не вижу преимущества хранения в YML
или
categories:
category_1:
id: 1
category_2:
id: 3
...
- это тоже идиотия
или
categories:
category_1
category_2
...
- ну, а тут как тогда связывать с сущностями в БД ? ManyToMany например. По ключу массива ? Ну так, а если я поменяю местами значения ? Или хранить в виде:
categories:
FIRST_CATEGORY: category_1
SECOND_CATEGORY: category_2
...
- а если таких 50 значений ? Для каждого писать конский ключ ?
Это не к вам претензии, вы не подумайте, просто у меня бомбит от ситуации.
