Мнения о использовании Doctrine во фреймворке.

AmdY

Пью пиво
Команда форума
Мнения о использовании Doctrine во фреймворке.

Попробовал Doctrine и был приятно удивлён отстутствие минусов в плане реализации ORM.
После недолгого раздумия попытался прикрутить её в разрабатываемый фреймворк. И сново особых проблем не испытал.
Вот и задумался всё ли так безоблачно.
Фреймворк пока не предпологается использовать в нагруженных проектах и по всей вероятность будет затачиваться под CRM.
Хотелось бы услышать о минусах Doctrine как ORM и уж если потянет в сторону, то о Propel второй ветки.

Минусы:
  1. Сырость продукта, не все функции работают, нужно либо ковыряться в коде, либо ждать пока исправят.
  2. проблеммы с квотированием (Решается неиспользованием зарезервированных слов)
    [/list=1]
 

nail

Новичок
Минус есть такой - недостаточная стабильность. Не все фичи, описанные в документации, работают.
Чтобы полноценно использовать Doctrine, надо быть готовым смотреть как он работает изнутри, создавать тикеты, возможно самому что-то править.

Если это не помеха - то в остальном все замечательно.
 

AmdY

Пью пиво
Команда форума
Кстати по правке, мне пришлось отключить автокомплит :( Несмотря на хорошую организацию кода, чувствуется, что под IDE код не заточен.
 

Scud

Новичок
При включении identifier quoting доктрина работать перестаёт ;)
А в остальном достаточно удобно, поданные тикеты исправляют достаточно оперативно.
Да и после изучения кода осталось ощущение что с комлексными ключами в Doctrine лучше не работать.
 

Wicked

Новичок
кто здесь?! :)

1) не работает автокомплит для моделей - из-за использования магических методов.
2) нету автоматической генерации миграций, и вообще непонятно, как его там по-правильному делать.
3) периодически встречаются баги, иногда откровенно тупые (последний: $dsn = str_replace("///c:/", "//c:/", $dsn); - кто найдет тут 3 ошибки? .-) ).
 

nail

Новичок
Wicked
А по миграциям ты последнюю версию смотрел? Они над этим активно работали.

[Вск Фев 17 2008] [12:17:06] <jwage> Doctrine_Migration_Diff
[Вск Фев 17 2008] [12:17:08] <jwage> yes
[Вск Фев 17 2008] [12:17:19] <jwage> I will have that working in 0.10.2
[Вск Фев 17 2008] [12:17:21] <gnat42> so will it modify the schema.yml as well?
[Вск Фев 17 2008] [12:17:23] <jwage> no
[Вск Фев 17 2008] [12:17:25] <gnat42> and or models?
[Вск Фев 17 2008] [12:17:28] <jwage> no
[Вск Фев 17 2008] [12:17:31] <jwage> you change your models
[Вск Фев 17 2008] [12:17:38] <jwage> and use the diff tool to compare your current db and models
[Вск Фев 17 2008] [12:17:42] <jwage> to generate a migrations class
[Вск Фев 17 2008] [12:17:45] <gnat42> ok
[Вск Фев 17 2008] [12:17:54] <jwage> or you change your schema files, and regenerate models
[Вск Фев 17 2008] [12:17:56] <jwage> then compare
[Вск Фев 17 2008] [12:17:58] <gnat42> will migrating from one version to another update the models?
[Вск Фев 17 2008] [12:18:19] <jwage> no, changing the models is what generates the migration
[Вск Фев 17 2008] [12:18:31] <gnat42> I guess
[Вск Фев 17 2008] [12:18:33] <jwage> the differences generated between your db and your models is what is used to bring your db up to date with your model sch
ema information
[Вск Фев 17 2008] [12:18:45] <jwage> So if you use schema files, you would change your schema files, regenerate your models
[Вск Фев 17 2008] [12:18:59] <jwage> then use the diff tool to generate a migration class from the differences between the db and your models
[Вск Фев 17 2008] [12:19:31] <jwage> I am gonna try and release 0.10.2 next friday or the friday after
 

Wicked

Новичок
> and use the diff tool to compare your current db and models

хорошо, что сделали, но плохо, что несколько лажово :) я примерно про это в своем топике в ГГ и писал, что дифф должен быть между однородными данными: либо модель-модель, либо схема-схема... Но в целом тут нету единственно правильного решения.
 

Gas

может по одной?
atv
какой engine таблиц в тесте был, innodb?
Если так, то мне кажется тесты insert/update/delete не совсем равнозначные для LightOrm и Propel/Doctrine, из-за beginTransaction/commit у LightOrm. Если без них попробовать или с их аналогами в Propel/Doctrine?

p.s. не ожидал что doctrine сольёт пропелу.
 

nail

Новичок
Gas
У Пропела функциональность по сравнению с Доктриной почти никакая.
 

Gas

может по одной?
nail
спорить не буду, особо не юзал. А насчёт тестов atv интересно, за счёт трикса (группировки всех операций в одну транзакцию) достигается такое превосходство LightOrm или всё по честному.
 

nail

Новичок
Gas
Да (в соседнем топике это обсуждаем). Плюс кеш запросов в доктрине скорее всего не работает.
 

AmdY

Пью пиво
Команда форума
atv скорость в данном случае не так важна у фреймворка другие задачи, хотя селекты конечно подтяну за счёт кеширования, да и думаю разработчики оптимизируют, я потому и использую сторонние библиотеки, чтобы часть разработки переложить со своих плеч.
Кстати, APC использовался при тестах? Доктирина где-то 60 файлов подтягивает у меня.
Мне ещё i18n не нравится, куча глюков, проще самому переписать.
а вот миграция полезная штука и думаю её быстро подтянут
 

Krishna

Продался Java
А что, доктрина совсем не умеет с транзакциями работать? :(
 

atv

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

Кстати, APC использовался при тестах?
Нет, в этом нет необходимости. При тестах замерялось чистое время, без учёта подключаемых файлов и т.д.

А что, доктрина совсем не умеет с транзакциями работать?
А с чего такие выводы? Если из тестов, так я там сперва неправильно их заюзал. Но теперь уже исправил, так что соотношение производительности кардинально изменилось.
 

nail

Новичок
atv
Надо использовать APC - в качестве opcode кеша - в Doctrine много кода подгружается. APC нужно включить для cli.
Еще желательно заюзать Doctrine.compiled.php.
 

atv

Новичок
Надо использовать APC - в качестве opcode кеша - в Doctrine много кода подгружается.
Я же говорю, что в тестах это время не учитывается. Вопрос то был, использовался ли APC в тестах. А в проекте, понятное дело, лучше использовать.
 
Сверху