Od jakiegoś czasu widać, że Doctrine zyskuje popularność wśród twórców (i społeczności) Symfony. Ostatnio na blogu symfony pojawiła się informacja, że Doctrine będzie domyślnym frameworkiem dla gałęzi 1.x poczynając od 1.3. W komentarzach jest wypowiedź jednego z twórców, że w gałęzi 2.x będzie wspierana tylko Doctrine.

W związku z tym, chciałbym was zapytać o odczucia w związku z Doctrine. Sam nie znam tego ORM, ale słyszałem trochę złego, szczególnie o fatalnej wydajności tego ORM. Mam projekt, który jest w wersji 1.0 oparty o Propela. Chciałem go przepisać do wersji 1.3 tak, aby korzystał z nowszej i szybszej wersji Propela, ale teraz zastanawiam się nad Doctrine... Problemem jest jednak jej wydajność, bo projekt jest dość mocno oblegany.

Jakie są zatem fakty o wydajności Doctrine? Pytam o wrażenia "real life", bo pseudo testy i benchmarki tak na prawdę nic nie mówią, o tym jak ORM będzie sprawował się w prawdziwej aplikacji.

Pytanie 2 - czy da się uzyskać podpowiadanie składni w Doctrine na miarę tego w Propelu - niby mała rzecz, ale strasznie ułatwia i przyspiesza pisanie.

Na pytania nie znam odpowiedzi, ale przyznam, że zmartwiło mnie to:


Że Doctrine nie będzie domyślny niezbyt mi przeszkadza, ale że go wywalą? Faktem jest, że zanim będzie wersja 2.x to pewnie parę lat minie, ale nie widzi mi się przepisywanie całego systemu na Doctrine, jeżeli zajdzie potrzeba przesiąść się na 2.x Trochę to bez sensu, tym bardziej, zę jak zaczynałem z Symfony, wszystko co widziałem na necie było pod Propela. Tyle osób z niego korzysta, więc po co przesiadać się na Doctrine. Sporo ludzi na niego narzeka.

A co do wydajności to w sumie, jeśli Fabien z ekipą stwierdzili tak, to pewnie mają ku temu solidne powody, a nie tylko głos ludu.

Z czytania między liniami wnoszę, że chodzi o tempo rozwoju Propela - mówiąc dosłownie brak tego rozwoju.
Aczkolwiek też nie wyobrażam sobie przesiadki na Doctrine w tej chwili.

BTW. Gałąź 2.0 może być szybciej niż się spodziewamy. Już mamy 3 duże wydanie symfony w gałęzi 1.x - myślę że jeszcze 1 lub 2 i będzie powoli rozwijana gałąź 2.0 - przy tym tempie to myślę, że za rok może półtora może być już coś konkretnego w tym temacie.

To fakt

Ciężko porównywać wydajność real life, bo żeby uzyskać wiarygodne wyniki to trzeba byłoby jeden projekt zrobić w dwóch wersjach. Doctrine ma cacheowanie w miarę przyjemnie udostępnione, więc go przyspieszy. W Doctrine możesz hydrować na tablice, czyli kolejna możliwość przyspieszenia.

Co do podpowiadania, to da się uzyskać podpowiadanie pól obiektu (czy jak kto woli kolumn) ale także obietów powiązanych. Jest to dostępne od wersji 1.1.

Jeszcze zostało do wydania 1.3, ma być wydane rok po 1.2 - czyli listopad 2009. Potem ma już być tylko 1.4 z tej gałęzi. Zrozumiałem, że wersja 1.4 ma usuwać elementy zdeprecjowane w wersji 1.3. Natomiast wersja 2.0 ma się ukazać przed 1.4, także również nie sądzę, że będzie trzeba długo czekać. Domyślam się, że Sensio ma już sporą część kodu, może tylko prototypy ale jednak.

Porzucenie Propela w symfony 2 może przynieść dobry efekt, że Propel się pozbiera, bo na razie to śpi. Sensio wolało sobie wziąć Doctrine, bo projekt ma potencjał i spore plany. Zobaczcie jak przyspiesza Doctrine w wersji 2, w dodatku oni na prawdę chcą zrobić Doctrine jako rozszerzenie do PHP. A to, że z związku z porzuceniem Propela będzie trzeba przepisać na Doctrine, to i tak będzie trzeba przepisać bo zmiany pewnie będą spore.

Wg mnie po prostu trzeba będzie dodatkowo ściągnąć sfPropelPlugin - wsparcie na pewno zostanie ze względu na obecnie dużą popularność.

@Crozin - wsparcie dla Propela to coś więcej niż plugin. Mniej lub bardziej cały framework jest pisany pod ORM - przykładowo do Propela dostajesz generator admina, generator formularzy etc. Boję się, że zabraknie tego typu rzeczy w Symfony 2.0 i wszystko będzie opierać się na Doctrine.
W komentarzach pojawiają się też głosy, że trudno jest utrzymać dokumentację dla 2 ORM'ów - w związku z tym, że Propel nie będzie już oficjalny, nie będzie dla niego pewnie dokumentacji.

Pytanie więc czy Propel ruszy z kopyta? Jeśli nawet ruszy to chyba mówiąc kolokwialnie i tak "już jest pozamiatane".

Sama decyzja o wspieraniu jednego ORM'a jest zrozumiała bo dzięki temu będzie można skupić się na nowych funkcjonalnościach, ale jednak mam sentyment do Propela i chętnie dalej pracował bym w oparciu o niego.
Jeśli Doctrine jest tak mało wydajne i niedopracowane jak ludzie mówią, to pytanie czy jest to dobry ruch. Z drugiej strony może to tylko lamenty bez pokrycia. Jedno jest jednak pewne, że jest to kolosalna zmiana i może się odbić niektórym czkawką.

@athabus: Wiem, wiem... chodzi mi o to, że prawdopodobnie "usługi" związane z Propelem w nowych wersjach pozostaną na obecnym poziomie, nie będą rozwijane, ale to co jest dziś - będzie.

Też pracowałem w oparciu o Propela, ale chciałem sprawdzić sobie jak Doctrine wygląda, bo w ogóle nie znam - teraz pewnie się jakoś zmobilizuję.

Walor edukacyjny ;-) Też chyba będę musiał zerknąć za wczasu.

doctrine też ma te generatory ...

Trochę wkurzające - jak już się porządnie zaprzyjaźniłem z propelem, poznałem jego kruczki, to chcą mi go zabrać jego pełne wsparcie z najlepszego frameworka.
No nic, pożyjemy, zobaczymy.

Jedna z osób pracujących nad rozwojem Doctrine - zdaje się Pan Wage chwalił się niedawno dużym wzrostem wydajności najnowszej wersji Doctrine (która to będzie w symfony 1.3). Doctrine na całe szczęście będzie domyślnym ORM w symfony 1.3. Bardzo dobrze, bo ten ORM ma składnię bardzo zbliżoną do SQL, nie to co jakieś dziwaczne criteria w Propelu. SQL to bardzo fajny język i nie wiem po co twórcy propela wymyślali jakieś cuda w swoim ORM bezczeszcząc ten język.
Polecam poniższe tutoriale o Doctrine:
http://blog.webarchitect.pl/2008/03/15/sel...ete-w-doctrine/ (część rzeczy w nim jest już nieaktualna, ale przyjemnie i treściwie wprowadza w świat doctrine)
http://www.symfony-project.org/doctrine/1_...rking-With-Data (tutorial symfony o doctrine - to co najpotrzebniejsze w jednym miejscu, obowiązkowa lektura jak komuś się nie chce czytać dokumentacji doctrine)

Jak widzicie ten ORM bardzo przypomina język SQL - na całe szczęście .

Wychodzi mi powoli, że doctrine to przyszłość - szczegółnie że na tracu propela nie było commita od ~miesiąca, a na stronie doctrine jest coś takiego w stopce: "Website powered by symfony and Doctrine".

Jeśli chodzi o Criteria... da się przywyknąć i polubić .

@nieraczek: możesz mi powiedzieć czy w Doctrine jest coś takiego jak nested set (drzewka) w propelu?

Tutaj potwierdzenie, że doctrine będzie domyslnym ORM: http://www.symfony-project.org/blog/2009/0...el-and-doctrine
As Doctrine is the future of symfony, we decided to make it the default choice when creating a new project

Co do nested set (drzewka) to nie potrafię odpowiedzieć na to pytanie, nie spotkałem się z takim pojęciem 'nested set', ale znalazłem na tej stronie taką informację:
"A i jeszcze jedno: w Doctrine póki co jest "tylko" jeden model struktury drzewiastej - NestedSet, pozostałe (MaterializedPath i AdjacencyList) są tylko w postaci pustych klas abstrakcyjnych."
http://www.zyxist.com/pokaz.php/doctrine

No nie żartujcie, ciretria są bardzo wygodne do budowania zapytań, zwłaszcza po uruchomieniu podpowiadania składni. Ogólnie będę tesknił za Propelem, bo to co widzę w Doctrine raczej mi nie odpowiada.

No ale fakt jest taki, że wszystkie znaki wskazują, że trzeba zacząć uczyć się Doctrine, jeśli chce się używać Symfony.

@Pr0100 - wiem, że Doctrine też ma od niedawna generatory - chodziło mi o to, że w wersji 2.0, która nie będzie wspierać Propela, pewnie nie będzie takich rzeczy dla tego ORM'a, także korzystanie z niego nie będzie juz takie wygodne jak teraz.

Witam,



Nawet więcej niż prototypy, skoro Dailymotion już wykorzystuje fragmenty (nie wiemy jednak jak duże) Symfony 2.



Ale właśnie to jest realizowane przez plugin. Plugin dostarcza nie tylko możliwość konfiguracji orma ale również taski do generowania admina, formularzy itp.



Chwalili się przyrostem wydajności w wersji 2.0 doctrina. Nie sądzę, że ta wersja zostanie wykorzystana w symfony 1.3 - programiści doctrina mają jeszcze przed sobą dużo pracy, a potem jeszcze trzeba będzie przepisać plugin. Raczej symfony 1.3 domyślnie będzie korzystało z wersji 1.1 albo 1.2 doctrina (o ile zdąrzą ją wypuścić).

A co do decyzji sensio odnośnie porzucenia oficjalnego wsparcia dla propela - to nie ma się czemu dziwić. Wystarczy spojrzeć na częstotliwość commitów:
http://propel.phpdb.org/trac/log/

Na chwilę obecną można stwierdzić, że ten projekt jest martwy. Więc po co mają inwestować czas w jego wsparcie? Trzeba też pamiętać, że sensio ma interes w tym, żeby programiści używali doctrina a nie propela. Są to szkolenia, które oferują (z symfony i doctrina). W końcu nie po to zatrudnili programistę doctrina, żeby teraz nie czerpać z tego korzyści finansowych.

A co do dalszego losu propela - nie sądzę, żeby to zagrożenie spowodowało dalszy jego rozwój. Myślę, że oo prostu brakuje programistów, którzy chcieliby go dalej rozwijać. Pewnie kod też już nie jest pierwszej świeżości i przydałby mu się porządny refactoring (tak, jak w doctrine 2.0).

Prawdopodobnie ktoś stworzy plugin dla propela, ale myślę, że wcześniej czy później ludzie i tak będą się od tego orma odsuwać (ze względu na brak rozwoju i poprawy błędów).

JA wciąż nie mogę się przyzwyczaić do Doctrine. Ten ORM mi sie zwyczajnie nie podoba.

Na szczęście ruszyło się kilka rzeczy w sprawie Propela:

1. Wpis Fabiena na Twitterze.
2. Propel, a Symfony 1.3
3. Devy Propela IRCują

Dziwi mnie ta "śmierć" Propel'a - może coś faktycznie się ruszy, ale wydaje mi się że będzie bardzo trudno rozruszać społeczność - pewnie się jej członkowie wypalili. Trzymam jednak kciuki bo bardzo lubię to rozwiązanie.

Nowy Dev Leader Propela to Francois Zaninotto - dosyć znana persona w światku Symfony. Wierzę, że da radę pociągnąć projekt.

Tak znam go z "czytania" jak chyba każdy kto cokolwiek robił w symfony.
Na pewno wie jak zarządzać społecznościami i zapewne jest niezłym developerem jednak łatwiej jest spłodzić dziecko niż ożywić trupa ;-)
Jeśli Propel ma szanse się wydobyć z zapaści to już tylko chyba może go uratować współpraca z Symfony - mam nadzieję że na to nie jest za późno. Na pewno będę trzymał kciuki. Szkoda, że nie jestem na tyle dobry aby móc pomóc programistycznie.

Jeżeli o mnie chodzi tak się przywiązałem do Propela, że jak będzie to konieczne to zgłoszę się gdzie trzeba.

Jestem z czytaczy źródeł, więc mam ułatwiony start

Jest pole do popisu np. bardzo brakuje mi kolekcji w Propelu. Moim zdaniem bardzo wpasowałyby się w Propelową filozofię



Propel jest do odratowania.

ludzie pytacie o podstawowe sprawy w doctrine, drzewa itp
wystarczy zerknac do dokumentacji.
http://www.doctrine-project.org/documentation/manual/1_1/en

Jakiś rok temu też tak mówiłem ... ale od kiedy wsiadłem na poważnie do Doctrine ... trudno jest porównywać: malucha do mercedesa .
Twórcy Doctrine mocno zainspirowali się logiką Hibernate'a ... i bardzo dobrze odbiło się to na filozofii projektu.

Generalnie kilka faktów:
- Propel nie jest rozwijany - czyli jeszcze trochę i rozwój aplikacji w propelu zostanie poważnie przychamowany
- jest wiele funkcjonalności, których z Propela nie "wyciśniesz" a z Doctrine'a tak;
- nie znam takiej funkcjonalności w Propelu, której nie uzyskasz w Doctrinie
- Doctrine ma wspierane dwa stabilne wydania (1.0 i 1.1), z czego trwają prace nad kolejnymi dwoma, w dwóch głównych gałęziach (1.2 i 2.0)

Podsumowanie:
Jeżeli planujesz małą aplikację, bez dłuższego rozwoju, to Propel jeszcze przejdzie.
Ale jeżeli chcesz realizować projekt przez 2 lata i mieć dostęp do kompletnej dokumentacji i aktualizacji aplikacji ... to bez Doctrina nie polecam .

To oczywiście był fakt, teraz przecież juz się to zmieniło, rozwój ruszył na nowo. Bardzo dobrze się stało, że zmienili się liderzy projektu, część ekipy też powinna być do wymiany, ponieważ zwyczajnie się wypalili.


Rzeczywiście masz rację, Doctrine ma trochę tych bajerów, ale nauka ich wykorzystania jest czasochłonna. Bez wątpienia ogromna przewaga to hydrowanie, ale w nowym Propelu ma się to również zmienić.


W takim razie napisz mi jak zrobić w Doctrine widok, tak żeby tworzył się dla niego model a także zapytanie sql. Napisz mi też jeszcze jak wgrywać automatycznie wyzwalacze (triggers) czy też np. procedury.
To przyszło mi na szybko do głowy, a pewnie znalazło by się więcej.

Na Twoim miejscu czytałbym więcej niż ostatnią stronę tematu przed napisaniem posta Tak na przyszłość.



Ja natomiast nigdy nie miałem problemu z uzyskaniem czegokolwiek w Propelu.



Ja natomiast nigdy nie miałem problemu z uzyskaniem czegokolwiek w Propelu.



Na tą chwilę możliwe. Jednak François Zaninotto pokazał, że potrafi pracować z OS/Społecznością OS. Mam w niego wiarę, że Propel odżyje.

napisz po polsku to moze cos poradzimy
serio - nie rozumiem tego zdania.

obslugi triggerow nie ma zdaje sie.

Odnośnie widoków, to powiem tak, a kiedy Ci się one przydają?
Bo do SELECTów wyciągania wyników, możesz również dobrze zbudować SQL'a (z Doctrinowego DQL'a) i masz taką samą wydajność.
A do aktualizacji rekordów (INSERT/UPDATE/DELETE), to niestety prawda jest dość smutna:
- PostgreSQL - jest tylko read/only
- MySQL - możesz aktualizować, tylko w przypadku relacji 1 do 1
I jak często wykorzystujesz widoki? A raczej zapytałbym, po co w Propelu musisz wykorzystywać widoki?
I dlaczego w Doctrine wystarczy Ci DQL?

No do triggerów, to murwazy ma chyba rację, bez haczyków chyba nie możesz w propelu wsadzić Triggerów - powód prosty:
ponieważ nie możesz później migrować pomiędzy różnymi bazami danych, a nie o to chodzi w ORM-ach.

Ale za to w Doctrine pomyślano o listenerach, w których możesz wywoływać metody w trakcie aktualizacji rekordu: po stronie aplikacji - a nie bazy danych.

Odnośnie stwierdzenia, że nie miałeś problemu z uzyskaniem czegoś w Propelu, to odpowiem tak: póki masz małą aplikację i w trakcie prac nie planujesz zmiany bazy danych - to chodzi Git ... korzystałem z niego z dobre 4 lata
Ale, jeżeli w celu poprawy wydajności zapytań (tu nie trzeba się rozwodzić, ile Propel potrafi zapytań narobić), próbujesz bawić się z createStatement, a potem zmieniasz bazę danych ... no to wtedy tylko dobre testy mogę Cię tylko uratować .

Jak komuś jeszcze się coś uda znaleźć, czego nie można zrobić w Doctrine, co się da w Propelu, to zapraszam do dyskusji .

Zapominasz, że Propel odżywa. Developerzy już dodali natywne Behaviory.

Sądzę, że Propel - dzięki solidnym fundamentom - szybko dogoni Doctrine.

P.S. Właśnie wyszła 1.4 alpha1

super, konkurencja to dobra sprawa:)
wczesniej samotny propel jakos osiadl na laurach i zatrzymal w rozwoju.

mi bardziej pasuje doctrine, Tobie propel. i wszystko w porzadku.

Nie zapominam.
A czy pamiętasz, że Propel jest prawie 2 razy starszy od Doctrina ? To kto kogo powinien gonić?
No bo teoretycznie, patrząc po historii, Propel ma 2 razy bardziej solidne fundamenty .

Ale jak napisał murwazy, dobrze że coś się dzieje.

Poza tym, odnośnie wersji Alfa - to kolejny krok milowy: Doctrine 2 się szykuje (to nie jest podwersja, ale całe wydanie do przodu).
I nie zapomniałem, że w planach mają również 2.0

Pod Propelem bazy akurat nie zmieniałem, ale zmiana bazy zawsze jest na tyle kłopotliwa, że dobre testy mogą się przydać. W każdej aplikacji może pojawić się coś nie do końca działającego z intencją.

Co do ilości zapytań, to mi Propel generuje idealną ilość... Ot po prostu gdy są bardziej skomplikowane zapytania/zadania to tworzę swoje własne konstrukcje używając Criteria albo sql'a. Dla mnie orm ma załatwiać podstawowe zapytania, przy tych newralgicznych wolę sam pomajsterkować. W Propelu tworzyłem już na prawdę skomplikowane konstrukcję gdzie ręcznie "hydrowałem" obiekty aby ograniczyć ilość zapytań - wszystko to jest możliwe w Propelu i nie jest nawet trudne do osiągnięcia. Także IMHO w bardziej skomplikowanych zadaniach Propel też się sprawdza, chyba że ktoś oczekuje, że ORM załatwi wszystko za nas.

Bolączką Propela w mojej opinii są dwie powiązane rzeczy:
- wydajność (ale tu inne orm'y nie są wcale lepsze)
- wielkość plików generowanych przez Propel'a przy wielu zdefiniowanych relacjach. Przy większych projektach wychodzą ogromne ilości kodu, co odbija się dodatkowo na wydajności.

Co jest też istotne to zapytania w Doctrine wyglądają jak te w Zend_Db czy Linq to SQL więc korzyść jest taka, że potem łatwo się przestawić. A w Propelu wygladają ... no dziwnie wygladają.

Może i na pierwszy rzut oka wyglądają dziwnie, ale po przyzwyczajeniu się do obiektu criteria zapytania tworzy się bardzo, bardzo prosto. Duży plus to podpowiadanie składni z nazwami pól w bazie etc. Dzięki temu nawet wracając po jakimś czasie do projektu nie trzeba znać bazy na pamięć, bo dzięki podpowiadaniu składni można wszystko podejrzeć w locie.

Rzuciłem okiem na propela 1.4 - wielkich zmian nie ma, ale jest ruch w dobrą stronę. Z tego co czytałem większe zmiany mają być planowane w 1.5. Propel ma też związać się mocniej z symfony, co akurat mi bardzo odpowiada i chyba nikogo nie dziwi. Na ircu wiele osób widzi w tym szansę na wyjście z impasu i chyba mają rację.

Rzuciłem już okiem na dokumentację (dziwna spraw, bo dokumentacja jest już dla alfy) - język żywcem wzięty z podręcznika do symfony - dużo przykładów i tekstów w stylu "wyboraź sobie, że masz taki problem - normalnie rozwiązałbyś go tak ale dzięki propelowi..." - kolejny ruch w dobrą stronę.

Myślę, że przyszłość zaczyna się rysować w jasnych barwach dla Propela. Po zapisie irca widzę, że jest trochę osób chętnych do pracy nad projektem tylko do tej pory zabrakło lidera, który by to wszystko ukierunkował. Myślę, że Francoise jest właściwą osobą we właściwym miejscu i pociągnie ten projekt. Szkoda, że nie mam umiejętności aby wspomóc projekt, bo w sumie to od niego zacząłem na poważnie wykorzystywanie gotowych rozwiązań i sentyment pozostał.

Nie jest dziwna - obecny project leader Propela pracował przecież nad dokumentacją dla Symfony. A że się poprztykał z Potencierem to inna sprawa

Z jego bloga:

Chodziło mi o to, że dokumentacja jest już dla Alfy ;-) Zazwyczaj w projektach OS dokumentacja rodzi się w bólach i jako ostatnia przychodzi na świat bo nikt nie chce jej pisać ;-)

A mi chodziło o to, że Zaninotto pracował dla Symfony, która również ma dokumentację dla swojej Alfy

Trzeba zauważyć że j,wage głowny dev doctrine, jest zarówno jednym z dev symfony, więc jak rozwija doctrine i symfony, to lepiej zrobić symfony na doctrine i święto lasu. Po co się męczyć jak tu piszę i tam piszę, a tak przynajmniej będzie miał łatwiej, rozumiem, popieram i jestem zadowolony.

A co do Propela, nie znam, nie używałem, używać nie będę.

W Doctrine wkurza mnie to że nie mogę wywoływać funkcji napisanych w sql, podczas pisania kodu w php. Ot tyle.

Stary napisz to po polsku, bo czytam to 3 raz i nie mogę zrozumieć co chcesz napisać. Co piszesz tu i tam, że jest święto lasu? :-)

Co ma piernik do wiatraka, że ktoś jest devem w symfony do tego, żeby zrezygnować z propela? Francois był też mocno związany z symfony więc mogę powiedzieć, żeby zrezygnować z doctrine, ale chyba nie o to chodzi.

Wydaje mi się, że Symfony może wspierać oba ORM'y. Wiele projektów stoi na propelu bo to był domyślny ORM od praktycznie samego początku. Zmuszanie ludzi do przepisywania całego modelu jest dość ryzykowną sprawą, bo często to >50% całej aplikacji.

Nie wiem, czy dobrze zrozumiałem to zdanie, jeśli jednak tak to przecież jest Doctrine_Expression ;]

Przeczytałem cały temat oraz troche info z innych stron i tak zastanawiam się na wyborem.

Z tego co zrozumiałem, to propel jest popularniejszy lecz miał okres kiedy spoczął na laurach (ale z tego co widze wrócili do pracy). Natomiast doctrine ma niewątpliwie tą ceche, że rozwija się systematycznie oraz jest preferowana przez projektantów Symfony, a co za tym idzie jest kwiestia czasu kiedy to Symfony będzie lepiej dzialać z Doctrine.

Tak więc moim zdaniem powinienem wybrać doctrine . Głownym powodem jest to, że bedzie miał większe wsparcie w przyszłości i jak dla mnie ma chyba lepsze perspektywy pozatym troche więcej tam z SQL'a pozostało, a lubie ten język).

Jeżeli sie mylę to prosze o skorygowanie tego bo dopiero zaczynam wiec jeszcze jest czas na zmiane

W Doctrine nie używa się SQL, chyba że wykonasz natywne zapytanie. Używa się natomiast DQL, który IMO jest naprawdę dobrym narzędziem.

IMO: Doctrine to lepszy wybór niż Propel (przynajmniej na chwilę obecną)

Marcstee Propel nie może być popularniejszy niż Doctrine skoro w głosowaniu nad rozwiązaniami, które powinny (były) pojawić się w Symfony 1.3/1.4 w trójce najpopularniejszych było 'uczynienie Doctrine domyślnym ORM', natomiast 'pozostawienie Propela domyslnym ORM' było daleko w tyle. To wlasnie miedzy innymi dlatego tworcy Symfony uczynili Doctrine domyslnym ORM, a w Symfony 2 Propel mial zostac w ogole usuniety (takie przynajmniej byly plany, moze juz sa nieaktualne jak mi zwrocil niedawno uwage batman ).

Uważam że porzucane Propela (bo to, że będzie wspierany przez sam FW to nie znaczy, że będę pluginy, a te częściej są kryterium wyboru ORM) to krok wstecz. Niestety Propel ma za długie okresy bez widocznego rozwoju. 1.2=>1.3=>1.4 w ile? Dobrych parę lat.
Składniowo wolę Propel z jego Criteria. Dlaczego? Bo tak

Pozwolę sobie odkopać temat.

Minął rok - widać już, że Propel ostro pracuje i stabilnie się rozwija. Niestety jakoś przestałem czytać bloga symfony i jestem nie na czasie.

Czy są jakieś wyraźne sygnały co do przyszłości Symfony 2.0 i Propel'a? Natrafiam tylko na strzępy informacji, z których wynika, że będzie można wykorzystać Propel'a w symfony 2.0, ale nie wiem czy będzie on jakoś specjalnie wspierany?

BTW. Po tym czasie cieszę się, że się myliłem a LBO miał rację - myślałem, że Propel umrze definitywnie, ale jakoś to wszystko pozbierało się do kupy i orm wraca na właściwe tory.

Moja druga obserwacja to to, że obawy o konieczność przepisania modelu pod Doctrine przy przejściu na Symfony 2.0 były bezpodstawne. Patrząc na przykłady kodu dostępne na stronie problem rozwiązał się sam - przejście z 1.x na 2.0 będzie wymagało chyba napisania całej aplikacji od nowa. Symfony 2.0 to zupełnie nowy framework. Trochę mnie to irytuje, że zmieniają co chwila koncepcje i nie dają im dojrzeć. Przykład formularzy: w 1.0 były helpery + validacja na podstawie plików yaml. Porem powstał subframework, dla którego do tej pory nie ma nawet pełnej dokumentacji (choć samo rozwiązanie przypadło mi do gustu). Teraz w 2.0 znowu będzie jakieś inne rozwiązanie. Aktualizowanie kodu do najnowszych wersji wymaga ogromnego nakładu pracy. Powiem szczerze, że ja do tej pory mam jedną większą aplikację napisana w symfony 1.0 i choć ciągle ją rozwijam, to nie zdecydowałem się na upgrade, bo musiałbym chyba z 3 tygodnie poświęcić na to.

Co do Doctrine 1.2 — 2.0: Zmieniono kompletnie podejście. Stary opierał się o ActiveRecord, architektura nowego całe szczęście została przebudowana, teraz mamy do czynienia z DataMapperem (i całe szczęście). Stąd też o ile schematy relacji można w miarę łatwo zaktualizować o tyle kod aplikacji (jej fragment dokładniej) trzeba kompletnie przepisać.

Jak wygląda przyszłość Propela w Sf2? Raczej niezbyt różowo. Nie jest on już udostępniany w głównej paczce frameworka, ale dostępny będzie w postaci osobnego pakietu (nie wiem jak inaczej sensownie przetłumaczyć słówko "bundle").

Propel 1 umrze powoli (ale zgodnością), bo nikt nie będzie chciał go używać z S2. To jest framework nowej generacji, tak samo jak D2 jest ORM nextgen i przynajmniej dla mnie pakowanie tam tego staruszka mija się z celem.

Na szczęście są plany odtworzenia Propela na bazie D2 - Propel2.



nie tłumacz, spalszczaj vide helpery.

edit:


Ale nie wcześniej niż przed końcem wsparcia dla symfony 1.4 - takie są koleje losu. Osobiście jestem wdzięczny Zaninotto, że podjął się wskrzeszenia Propela. Zrobił to z klasą wdrażając faktyczny roadmap, test-driven-development i to w czym kolo jest najlepszy, czyli czytelna dokumentacja nadążająca za projektem.

Dlatego pisząc o śmierci Propela 1, związane są z tym zupełnie inne uczucia niż rok temu. Jestem pewien, że Propel2 to będzie strzał w dziesiątkę, chociażby dlatego, że nie każdy będzie chciał programować z DDD - to jest trudne, wymaga dużej wiedzy i jeszcze więcej czasu.
ORM 1:1 z bazą danych zawsze będą potrzebne.