Adam W.

Adam W. senior php
developer, Symfony

Temat: doctrine vs propel

witam,

właśnie rozpocząłem nowy projekt korzystająć z Symfony 1.2.2 oraz Doctrine.
jak na razie wrażenia bardzo pozytywne:) można robić elegancko left joiny i bardzo fajnie to wszystko zamienia automatycznie na obiekty.

jak jest w Waszych projektach? korzystacie z Doctrine czy raczej z Propel 1.3, który jest w wersji 1.2.2 Symfony.
zauważyliście jakieś wady, gorsze rozwiązania niż w Propelu czy coś innego co powoduje że wolicie używać Propela?

chciałbym poznać Waszą opinię, bo nie wiem czy się pchać w Doctrine. wiadomo, że później będzie ciężko przepisywać wszystko na Propela.

konto usunięte

Temat: doctrine vs propel

Adam W.:

chciałbym poznać Waszą opinię, bo nie wiem czy się pchać w Doctrine. wiadomo, że później będzie ciężko przepisywać wszystko na Propela.

Ja bym czegoś większego nie stawiał na doctrine. Propel ma większy staż i wiele upierdliwych problemów za sobą + wsparcie community symfony.
Jeżeli to jakoś mniejszy projekt to spróbuj i podziel się wrażeniami ;-)
Adam W.

Adam W. senior php
developer, Symfony

Temat: doctrine vs propel

Michał Wujas:
Ja bym czegoś większego nie stawiał na doctrine. Propel ma większy staż i wiele upierdliwych problemów za sobą + wsparcie community symfony.
Jeżeli to jakoś mniejszy projekt to spróbuj i podziel się wrażeniami ;-)

od małych i szybkich projektów jest kohana:)
symfony + doctrine chciałem użyć do czegoś większego.
spróbuje jeszcze nowego Propela. zobaczę jak to jest z łatwością tworzenia skomplikowanych powiązań - hydrate:)
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

Michał Wujas:
Ja bym czegoś większego nie stawiał na doctrine. Propel ma większy staż i wiele upierdliwych problemów za sobą + wsparcie community symfony.

Może i Propel ma wsparcie community symfony (był pierwszy), ale odnoszę wrażenie, że zespół developerów symfony bardziej promuje doctrine (w końcu firma Sensio Labs, która zajmuje się Symfony, zatrudniła na etat faceta tylko do Doctrine - autora, o ile mnie pamięć nie myli).

Co do moich spostrzeżeń: zrobiłem 2 projekty na sf 1.0 z użyciem propela i 2 na sf 1.1 z użyciem doctrine. Doctrine jest dla mnie odpowiedniejsze. DQL jest wygodny, relacje M:N są wygodne, dokumentacja jest dość fajna. Propel ma z kolei więcej gotowych wtyczek do Symfony (w tym więcej behaviourów), ale jego wyjście poza zwykły select jest czasami bolesne (szczególnie w bardziej skomplikowanych zapytaniach, złączeniach M:N). Nie wiem jak to wygląda w najnowszym Propelu, być może coś poprawili, ale na poziomie gdy znałem dobrze propela i poznawałem doctrine, to ten drugi wypadał znacznie lepiej.

Jedyną rzeczą, która przeraża mnie w Doctrine to narzut, wydaje mi się, że większy niż Propela.
Adam W.

Adam W. senior php
developer, Symfony

Temat: doctrine vs propel

Wojciech Sznapka:
Jedyną rzeczą, która przeraża mnie w Doctrine to narzut, wydaje mi się, że większy niż Propela.

mógłbyś rozwinąć trochę tą myśl? jaki narzut, czego?
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

przede wszystkim zużycie pamięci. ponad 10 MB to jednak trochę sporo na wyrenderowanie prostej strony i wkonanie jednego selecta.
Adam W.

Adam W. senior php
developer, Symfony

Temat: doctrine vs propel

Wojciech Sznapka:
przede wszystkim zużycie pamięci. ponad 10 MB to jednak trochę sporo na wyrenderowanie prostej strony i wkonanie jednego selecta.

a co wpływa na ilość używanej pamięci?
bo jeśli chodzi o wielkości plików w katalogu model to te generowane przez Doctrine są o wiele mniejsze. a przy tym modele z Doctrine są chyba tak samo funkcjonalne. też można korzystać z setterów i getterów albo wprost odnosić się do właściwości. chociaż nie wiem czy to jest zgodne z paradygmatem enkapsulacji;)
Propel w wersji 1.2 zużywa równie dużo. ale czy to tylko propel zużywa czy ogólnie Symfony:) raczej symfony i to chyba nie ma znaczenia jaki plugin zostanie użyty do obsługi danych.

konto usunięte

Temat: doctrine vs propel

czytałeś ComparingPropelAndDoctrine ? [może trochę stare, ale jest :P]

na goldenline założyłem dawno temu podobny topic, mozę znajdziesz coś ciekawego propel czy doctrine ?

z tym zużyciem pamięci w przypadku propela to m.in rozmiary plików, przy dużych tabelach, z kilkoma relacjami i masą własnych funkcji to te pliki trochę zajmują [przynajmniej w symfony 1.0, nie wiem jak to jest teraz bo nie miałem czasu żeby ogarnąć symfony 1.2]

a z doctrine to nie jest tak że za każdym wywołaniem coś generuje? nie pamiętam dokładnie ...

Temat: doctrine vs propel

IMHO Propel jest dobry jeżeli pisze się naprawdę proste strony, ale zrobienie takiego czegoś, jak np zrobienie podwójnego joina lub porównanie dwóch kolumn w WHERE odpada (odhachone jako ważny bug, ale do zrobenia dopiero w ver.2). Wiele osób posiłkuje się pisaniem czystych SQL-ek, ale wg mnie nie tędy droga jeżeli korzysta się z ORM-a.
Pisze z reguły bardziej zaawansowane logicznie witryny i Doctrine jest jak dla mnie jak najbardziej naj, szczególnie jeżeli chodzi o DQL i joinowanie tego co potrzeba. Ból jest tylko taki, iż Doctrine korzysta z metod magicznych i Eclipse/NetBeans nie podpowiada mi składni, ale da się przeboleć ;)
Adam W.

Adam W. senior php
developer, Symfony

Temat: doctrine vs propel

Paweł Smoliński:
o DQL i joinowanie tego co potrzeba. Ból jest tylko taki, iż Doctrine korzysta z metod magicznych i Eclipse/NetBeans nie podpowiada mi składni, ale da się przeboleć ;)

chodzi Ci o to, że nie podpowiada nazw kolumn? można zrobić to samo co w Propelu, czyli dopisanie setterów i getterów. a najlepiej to jakiś automat napisać:)

Temat: doctrine vs propel

Adam W.:
chodzi Ci o to, że nie podpowiada nazw kolumn? można zrobić to samo co w Propelu, czyli dopisanie setterów i getterów. a najlepiej to jakiś automat napisać:)
Dokładnie o to mi chodzi ;) Jednak bardziej odpowiada mi odwoływanie się przez Obiekt->nazwa aniżeli Obiekt->getNazwa() (z Propelem się za bardzo kojarzy ;-P) - możnaby ewentualnie napisać plugina do Eclipse'a/NetBeans który przeskanowałby pliki modelu i odpowiednio generowałby podpowiedzi ;)

konto usunięte

Temat: doctrine vs propel

Paweł Smoliński:
IMHO Propel jest dobry jeżeli pisze się naprawdę proste strony,

Pojechałeś po bandzie z tymi naprawdę prostymi stronami.
ale zrobienie takiego czegoś, jak np zrobienie podwójnego joina lub porównanie dwóch kolumn w WHERE odpada (odhachone jako ważny bug, ale do zrobenia dopiero w ver.2).

Na aliasach można zrobić.
Wiele osób posiłkuje się pisaniem czystych SQL-ek, ale wg mnie nie tędy droga jeżeli korzysta się z ORM-a.
Pisze z reguły bardziej zaawansowane logicznie witryny i Doctrine jest jak dla mnie jak najbardziej naj, szczególnie jeżeli chodzi o DQL i joinowanie tego co potrzeba.

Jeszcze są triggery, procedury, widoki i tego orm nie zapewni, a to wiąże się z zaawansowaną logiką. Podwójne joiny służą zwykle do jakichś sztuczek, których powinno się unikać.
Ból jest tylko taki, iż Doctrine korzysta z metod magicznych i Eclipse/NetBeans nie podpowiada mi składni, ale da się przeboleć ;)

To jedna z głównych zalet Propela, sprawdzanie nazwy pól przy kodowaniu systemów z liczbą kolumn liczoną w setkach jest wtedy mocno upierdliwe.

Temat: doctrine vs propel

Całkowicie się z tobą zgadzam, ale i tak pozostanę przy Doctrine ;) Gdy używałem Propla także posiłkowałem się widokami tylko i wyłącznie po to, aby mógł korzystać z procedur składowych (a dokładniej sprawa polegała na tym, iż pewna funkcja (procedura składowa) foo(u1, u2) zwracała pewien współczynnik opisujący zależności między userem o id=u1 a userem o id=u2. Następnie musiałem wyciąć z listy userów, dla których wynik ten był mniejszy od pewnej ustalonej wartości w (czyli foo(u1, u2) < w) i wynik całej tej operacji wrzucić do pagera. W Proplu bez widoków jest to niewykonalne, w Doctrinie sprawę załatwia się od ręki.
Oczywiście można unikać robienia podwójnych joinów, bawić się aliasami i tworzyć setki widoków, których można byłoby uniknąć (pod warunkiem oczywiście, iż zapomnimy o wrzucaniu do kodu czystych SQLek) ale IMHO tworzy to niepotrzebny i z reguły ciężko modyfikowalny bałagan w kodzie ;)
Łukasz Krzysiak

Łukasz Krzysiak programista, o2.pl

Temat: doctrine vs propel

Jeśli o mnie chodzi to zdecydowanie Doctrine. Przedewszystkim ze względu na przejrzystość DQLa, wygodne tworzenie joinów no i obsugę typów wyliczeniowych.

konto usunięte

Temat: doctrine vs propel

A mnie, np. ostatnio Doctrine zawiódł trochę gdy chciałem go wykorzystać przy projekcie z PostgreSQL, używając przy tym Symfony 1.2.5.
Ma problemy z wygenerowaniem schematu z gotowej bazy, w której występują relacje pomiędzy tabelami.

Mimo wszystko w używaniu z MySQL jak najbardziej Doctrine.

konto usunięte

Temat: doctrine vs propel

Przemysław Ciąćka:
A mnie, np. ostatnio Doctrine zawiódł trochę gdy chciałem go wykorzystać przy projekcie z PostgreSQL, używając przy tym Symfony 1.2.5.
Ma problemy z wygenerowaniem schematu z gotowej bazy, w której występują relacje pomiędzy tabelami.

Mimo wszystko w używaniu z MySQL jak najbardziej Doctrine.

Docrtin + postgres = nie rob tego ;) sporo sie chlopaki pochwalili, czego to tam nie ma, a w kodzie zrodlowym niestety bida :) zeby nie powiedziec z nedza :) ogolnie to doctrine to jest chyba taki mysql orm :D a reszta to tylko propaganda...
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

Krzysztof Staniszewski:
Przemysław Ciąćka:
A mnie, np. ostatnio Doctrine zawiódł trochę gdy chciałem go wykorzystać przy projekcie z PostgreSQL, używając przy tym Symfony 1.2.5.
Ma problemy z wygenerowaniem schematu z gotowej bazy, w której występują relacje pomiędzy tabelami.

Mimo wszystko w używaniu z MySQL jak najbardziej Doctrine.

Docrtin + postgres = nie rob tego ;) sporo sie chlopaki pochwalili, czego to tam nie ma, a w kodzie zrodlowym niestety bida :) zeby nie powiedziec z nedza :) ogolnie to doctrine to jest chyba taki mysql orm :D a reszta to tylko propaganda...

A co nie działa? Ja używam Doctrine + Postgres i póki co, poza warningami z doctrine:build-sql, na inne problemy nie natrafiłem.

konto usunięte

Temat: doctrine vs propel

Wojciech Sznapka:

A co nie działa? Ja używam Doctrine + Postgres i póki co, poza warningami z doctrine:build-sql, na inne problemy nie natrafiłem.

Od dłuższego czasu nie robiłem nic używając PHP i Doctrine.
Ale z tego co pamiętam miałem problemy z wybieraniem danych z tabel - PostgreSQL zwracał błędy, np. nazwy tabel, kolumn nie zostały objęte poprawnie w cudzysłowie.
Poza tym problem z budowaniem schematów na podstawie istniejących tabel w bazie.
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: doctrine vs propel

Przemysław Ciąćka:
Od dłuższego czasu nie robiłem nic używając PHP i Doctrine.
Ale z tego co pamiętam miałem problemy z wybieraniem danych z tabel - PostgreSQL zwracał błędy, np. nazwy tabel, kolumn nie zostały objęte poprawnie w cudzysłowie.
robię na Postgresie 8.3 i Doctrine 1.1 - nic takiego mnie nie spotkało.
Poza tym problem z budowaniem schematów na podstawie istniejących tabel w bazie.
to mi nie było potrzebne :-)

Poza tym, mam dość złożony system, dużo joinów, parę miejsc, w których intensywnie używam transakcji. Zapierdziela, że aż miło :-) A o PgAdminie już nie wspominam, bo to poezja :-)Wojciech Sznapka edytował(a) ten post dnia 06.12.09 o godzinie 12:08

konto usunięte

Temat: doctrine vs propel

Wojciech Sznapka:

Poza tym, mam dość złożony system, dużo joinów, parę miejsc, w których intensywnie używam transakcji. Zapierdziela, że aż miło :-) A o PgAdminie już nie wspominam, bo to poezja :-)[edited]Wojciech Sznapka edytował(a) ten post dnia 06.12.09 o

O, no to ciekawie, jeśli śmiga bez problemów no to super...w wolnej chwili będę musiał potestować :)



Wyślij zaproszenie do