1.1
Ámon Tamás
Talan erdekes lehet:
http://www.symfony-project.org/blog/2007/11/18/the-new-form-framework-is-almost-there
--
Ámon Tamás
Aston
Valamiért elsiklottam felette. Ahogy nézem nagyon drasztikus változás
nem lesz benne. A plusszoknak megörüljünk :).
> Talan erdekes lehet:http://www.symfony-project.org/blog/2007/11/18/the-new-form-framework...
> --
> Ámon Tamás
Sulik Szabolcs
Elkezdtem egy bejegyzés-sorozatot a blogszerűségemben (http://
blerou.extra.hu), ami a symfony 1.1 újdonságait mutatja be.
Ha úgy gondoljátok, hogy használható, feltehetünk valami hasonlót a
készülő symfony.hu-ra is.
Tamas Amon
Itt is van egy majdnem hasonlo:
http://www.symfony-framework.com/2007/11/23/symfony-11-whats-new/
Egyebkent mi ez a doctrina vagy mi? Vagyis miert lesz ez jobb mint a
propel?
Aston
A Doctrine egy ORM mint a Propel, állítólag sokkal jobb, gyorsabb meg
jobban dokumentált. Egyelőre csak pluginként van támogatva a
symfonyban, de állítólag jó lehet használni.
Egy pár vélemény itt: http://weblabor.hu/cikkek/a-symfony-keretrendszer-telepitese-es-bemutatasa#comment-47875
Üdv,
Aston
Zoltán Németh
> Szia!
>
> Itt is van egy majdnem hasonlo:
> http://www.symfony-framework.com/2007/11/23/symfony-11-whats-new/
>
> Egyebkent mi ez a doctrina vagy mi? Vagyis miert lesz ez jobb mint a
> propel?
doctrine ORM
http://trac.phpdoctrine.org/
szvsz a legnagyobb előnye a propelhez képest hogy van benne valódi
öröklődés:
http://www.phpdoctrine.org/documentation/manual?one-page#relations:inheritance
és hierarchikus adatszerkezetek (tree):
http://www.phpdoctrine.org/documentation/manual?one-page#hierarchical-data
emellett jól van dokumentálva, és azt mondják gyorsabb is.
csak azért nem álltunk még át rá mert nincs még belőle stable release.
(mondjuk az átállás valszeg nagyon PITA lesz...)
üdv
#z
Tamas Amon
1.1-ben.
--
Tamas Amon <sajt...@gmail.com>
Zoltán Németh
> Csak azert kerdezem, mert allitolag ez lesz az alapertelmezett az
> 1.1-ben.
én úgy tudom az 1.1-ben még nem, mivel addigra nem lesz stable doctrine
de később valszeg igen
üdv
#z
Cece
Olyan is felmerült valahol, hogy a propel is csak plugin lesz, nem
lesz beldrótozva
a rendszerbe. Kiderül, mert ahogy nézem, a tűzhöz közel állók véleménye is
elég sokféle.
A Propel Object/ObjectPeer felállása joban tetszik a Doctrine megoldásánál
és nekem a Criteria építés sem volt rossz. Igaz, pár dolog hibádzik, mint
az aggregát függvények használata (ha csak nem nyers queryként).
Eleinte azért is ferde szemmel néztem a Doctrine-re, mert sok olyan plugin
nem volt meg hozzá, ami propel-hez van. De jó tudni, hogy pl a sok
sfPropelXYBehavior plugin jó része a doctrine-nek eleve része, azaz
pl alapból tudja a Versionable behavior-t. Szintén jobb (állítólag) abban,
ami a Propel gyengesége, hogy nem tud a saját és a plugin sémájával
együtt dolgozni. Elsőre csúnyának véltem a Doctrine-ben azt, hogy
a setter getter eljárások helyett sima $this->valami = "érték"; formában
kell megadni a propertyket, de mint kiderült, emellett vannak setXy, getXY
virtuális fgv-ek is. Szóval nem rossz.
Viszont vigyázat, mert pl igaz van versionable támogatás a Doctrine-ben,.
mindenesetre a legfrissebb 1.0-ás Symfony a legfrissebb Doctrine pluginnel
nem működik rendesen. A Doctrine doksi szerint dolgozva nem pont
a kívánt eredményt hozza a dolog, szóval kicsit még instabilnak látom.
Persze lehet csak velem és a kis Doctrine tapasztalatommal van a baj.
Cece
Zsolt Takács
tehát az 1.1ben már az lesz.
Szerintem a peer-es mezőnév konstansos dolog felesleges bonyolítás a
propelben, ide-oda konvertálgatni a mezőneveket, a criteriák is eléggé
fapadosak bizonyos esetekben. A doctrineon látszik hogy rendesen végig
lett gondolva, sokkal elegánsabb megoldások vannak benne.
A doctrinet meg nem probaltam, csak a doksit olvastam, viszont a
propellel egy elég nagy projektet kezdtünk el, és egyre több csak a
gond vele.
Zs.
Krnák János
a criteriakkal neha nekem is gondom van amikor vmi osszetetteb dolgot szeretnek
bar foleg az aggregalt fuggvenyek hianyoznak :S
udv
Jani
Cece
> Szerintem a peer-es mezőnév konstansos dolog felesleges bonyolítás a
> propelben, ide-oda konvertálgatni a mezőneveket, a criteriák is eléggé
> fapadosak bizonyos esetekben. A doctrineon látszik hogy rendesen végig
> lett gondolva, sokkal elegánsabb megoldások vannak benne.
A konstansos dologgal eddig volt egy jó tapasztalatom. Volt egy doSelect()-em,
amiben a konstans helyett sima 'id' stringet adtam meg egy szűrőfeltételnél.
Később egy doSelectJoinAll()-ra lett cserélve a dolog, innentől persze jöttek
a gondok. Ha XYPeer::ID lett volna odatéve, ezt a kört megúszom.
Egyébként nagy projekteknél valóban lehetnek gondok, de ezek szvsz leginkább
ORM problémák by design. Az pedig már szemlélet kérdése, hogy egy okos
query-vel akarja-e az ember megoldani, ami esetleg OOP szempontból nem
olyan szép, ugyanis összemosódnak hamar a keresztbelekérdezésektől
a hatáskörök més oda a karbantarthatóság, átláthatóság.
Ha már erősen OOP a keretrendszer, én igyekszem inkább karbantartható
kódot gyártani, ha kell 1 helyett 3 queryvel, amit viszont erős function cache
támogatással orvoslok. (kellemes vitaalap) :)
> A doctrinet meg nem probaltam, csak a doksit olvastam, viszont a
> propellel egy elég nagy projektet kezdtünk el, és egyre több csak a
> gond vele.
Szvsz hasznos lehet, ha van némi időd egy új threadben ezeket a gondokat
felvetni, hátha másnak segít egy döntéshozatalban, vagy ha más nem
rágódunk egy jót a problémáitokon, hátha valami hasznos is kisül belőle.
Cece
Cece
Mindenképp hasznos a jövőre nézve...
Zoltán Németh
> Helló!
>
> > Szerintem a peer-es mezőnév konstansos dolog felesleges bonyolítás a
> > propelben, ide-oda konvertálgatni a mezőneveket, a criteriák is eléggé
> > fapadosak bizonyos esetekben. A doctrineon látszik hogy rendesen végig
> > lett gondolva, sokkal elegánsabb megoldások vannak benne.
>
> A konstansos dologgal eddig volt egy jó tapasztalatom. Volt egy doSelect()-em,
> amiben a konstans helyett sima 'id' stringet adtam meg egy szűrőfeltételnél.
> Később egy doSelectJoinAll()-ra lett cserélve a dolog, innentől persze jöttek
> a gondok. Ha XYPeer::ID lett volna odatéve, ezt a kört megúszom.
>
> Egyébként nagy projekteknél valóban lehetnek gondok, de ezek szvsz leginkább
> ORM problémák by design. Az pedig már szemlélet kérdése, hogy egy okos
> query-vel akarja-e az ember megoldani, ami esetleg OOP szempontból nem
> olyan szép, ugyanis összemosódnak hamar a keresztbelekérdezésektől
> a hatáskörök més oda a karbantarthatóság, átláthatóság.
ezt azért vitatnám, nálunk pl az egyik legnagyobb probléma az öröklődés
hiánya.
>
> Ha már erősen OOP a keretrendszer, én igyekszem inkább karbantartható
> kódot gyártani, ha kell 1 helyett 3 queryvel, amit viszont erős function cache
> támogatással orvoslok. (kellemes vitaalap) :)
ebben egyetértek, mi sem megyünk rá ilyen optimalizációra, annyi query
van amennyi az ORMből kijön ;)
aztán ha előrébb halad a projekt, majd kesselünk mi is mint atom :D
üdv
#z
Cece
> > ORM problémák by design. Az pedig már szemlélet kérdése, hogy egy okos
> > query-vel akarja-e az ember megoldani, ami esetleg OOP szempontból nem
> > olyan szép, ugyanis összemosódnak hamar a keresztbelekérdezésektől
> > a hatáskörök més oda a karbantarthatóság, átláthatóság.
>
> ezt azért vitatnám, nálunk pl az egyik legnagyobb probléma az öröklődés
> hiánya.
Részleteket, részleteket!
Tanuljunk már egymás szopásából, azért is van ez a lista...
Érdekes lehet szvsz a kitűzött cél és hogy hol találtátok
az úton a keresztbe dőlt fát Propel néven. :)
Cece
Zoltán Németh
hát, konkrét részleteket nem árulhatok el, a szerződésem tiltja ;)
de egy hasonló példa: tegyük fel van egy 'company' táblád, van továbbá
'client' és 'vendor'. a 'company' táblában szerepelnek cégek, amik
lehetnek emellett ügyfelek vagy beszállítók is. a 'client' ill. 'vendor'
táblában csak azok az adatok vannak amik specifikusak a cégtípusra, a
többi a 'company'-ban. ilyenkor a client-nek nincs getName() metódusa
például, mert a neve a company-ban van. rakás helyzetben kényelmes lenne
ha a client-ből elérhetnéd egyből a company metódusait, amit megtehetnél
ha a client-et definiálhatnád így:
class client extends company
ez az ami nincs a propelben, úgyhogy mindenféle workaroundokat kell
alkalmazni.
aztán még durvább a helyzet ha többszintű öröklődés van...
másik nagy gond, hogy a propel nem tud mit kezdeni a többfele mutató
kvázi-foreign keyekkel. tehát amikor egy táblában tárolsz egy táblanevet
meg egy foreign id-t és e kettő segítségével akarsz hivatkozni valami
más objektumra (amelynek típusa nyilván a hivatkozott táblától függ).
ennek feloldására saját generátort vetünk be, ami a BaseXY és az XY
class közé generál egy OurXY classt így:
class BaseXY {}
class OurXY extends BaseXY {}
class XY extends OurXY {}
és ez foglalkozik az ilyen referenciák kezelésével.
a sima öröklődés (akárhány szintű) egyszerűen meg van oldva a
Doctrine-ban, simán extend-elhetsz és kész, a többirányú referenciákat
igazából nem tudom...
üdv
#z
>
> >
Aston
$client->getCompany()->getName()
Akkor tényle, de a Client.php-ban csinálsz egy függvényt, hogy
function getName()
{
$this->getCompany()->getName();
}
Akkor ennyi. Ha azt mondod, hogy ez ilyen formában lassabb mint az
öröklődés akkor lehet hogy igazad van, de szerintem ez nem túl nagy
wordaround :).
aston
Zoltán Németh
> Hát ha az a workaround, hogy
>
> $client->getCompany()->getName()
>
> Akkor tényle, de a Client.php-ban csinálsz egy függvényt, hogy
>
> function getName()
> {
> $this->getCompany()->getName();
> }
>
> Akkor ennyi. Ha azt mondod, hogy ez ilyen formában lassabb mint az
> öröklődés akkor lehet hogy igazad van, de szerintem ez nem túl nagy
> wordaround :).
persze, egy táblánál nem vészes. de ha sok van, akkor vagy generátort
írsz rá hogy megcsinálja ezeket neked (ami elég macerás mert tudnia kell
hogy melyik metódusokat akarod örököltetni, tehát mondjuk yml-ben
konfigolhatónak kell lennie stb), vagy rengeteg ilyet kell kézzel
legyártani... igazából a kézi megoldás nem megoldás, ha gyakran
generálod újra a sémát (ami fejlesztés kezdeti szakaszában jellemző),
mert még ctrl-c-ctrl-v megoldással is sok... szóval egy csomó időt
elvisz hogy generátort írj ami olyan metódusokat generál amikre igazából
nem is lenne szükség ha lenne valódi öröklődés.
üdv
#z
Aston
Aston
Zoltán Németh
> Jogos, szóval a Doctrine közvetlenül generál getName függvényt ?
> Aston
nem egészen. valódi öröklődés van benne, tehát elég annyit mondanod hogy
class client extends company
és kész
üdv
#z
Tamas Amon
2007. 12. 5, szerda keltezéssel 08.48-kor Zoltán Németh ezt írta:
> 2007. 12. 4, kedd keltezéssel 13.27-kor Aston ezt írta:
> > Jogos, szóval a Doctrine közvetlenül generál getName függvényt ?
>
> > Aston
>
>
> nem egészen. valódi öröklődés van benne, tehát elég annyit mondanod hogy
> class client extends company
> és kész
>
Ez ilyenkor mit jelent? 1:1-es kapcsolatot? Es hogy van ez n:n-e
kapcsolatnal?
--
Tamas Amon <sajt...@gmail.com>
Zoltán Németh
n:n esetében nem lehet öröklődésről beszélni. 1:1 vagy n:1 lehet (mert
hát a gyerekből akárhány példány lehet)
n:n-t 'hagyományos' módon így lehet a doctrine-ban:
http://www.phpdoctrine.org/documentation/manual?one-page#relations:join-table-associations:many-to-many
üdv
#z
Cece
Kicsit utánaolvastam a Doctrine öröklődéssel és relációkkal kapcsolatos
dolgainak. Nem rossz, nem rossz. Mindjárt csak az öröklődés megvalósítására
is három módszert vonultat fel:
* Az öröklött class számára létrehozott táblában csak a speciális, rá
vonatkozó mezőket tárolja. Ettől függetlenül számunkra átlátszó
a dolog, azaz úgy kérjük le az objektumot, mintha minden egy helyen
lenne, a Doctrine pedig ezt lefotdítja egy join-os lekérésre.
* Megmondható (a szülő setTableDefinition() explicit meghívásával,
hogy márpedig mindent örököl az utód. Ekkor tehát csak a modell
generálásakor jut érvényre az örökődés. Minden bizonnyal gyorsabb
lekéréseket, de kissebb rugalmasságot ad
* Lehet egy táblában aggregálni az összes gyermek tulajdonságát,
és kijelölni egy mezőt (type néven pl., ami egy integer), amiben
meghatározzuk, hogy az adott adatbázis rekord melyik gyermekosztályhoz
tartozik.
Igazából mindegyik megoldást uganúgy használjuk, csak perormance
és rugalmasság terén skálázódik, melyik megoldás mikor jó.
Szóval egyre jobban tetszik a dolog. :)
Viszont annak sem a doksiban, sem másutt még a halvány nyomát
sem találtam, hogy akár a Propel, akár a Doctrine esetében megadható
lenne bármi formában, hogy egy reláció két mező értékén múljon.
Azaz pl egy objektumhoz egy másik objektum adott verzióját kössem
például. Azaz egy id és egy version mező kell mind a cél, mind a hivatkozó
adatbázis rekordba. Ha ebben valaki megcáfol, annak tudnék örülni. :)
A verzióknak is van saját egyedi id-jük, csak az ez sfPropelVersionableBehavior
megvalósításában egy uuid néven futó hash, ami nem igazán szimpatikus
lehetőség. Mindegy, egyéb megvalósításbeni problémák is vannak
ezzel a pluginnel, de legalább működik. :)
Viszont a többfelé mutató foreign key megvalósítás még durvábban
hangzik, ekkor ugyanis nem egy fix objektum mutat egy másikra,
hanem egy fix objektum egy dinamikusan változó class-ű másikra.
A Doctrine öröklődése valóban megoldás lehet erre, mivel az id-kat
a szülő class osztja, tehát egy id-ról bizton lehet tudni, milyen osztályú.
Az egyetlen feltétel az, hogy minden kötni való objektumot ugyanazon
szülőtől kell leszármaztatni. Hogy mennyire könnyű egy nyers id-ból
a szülő számára kideríteni, hogy melyik gyermekosztályé az adott
rekord, az még kérdéses, de megoldható. Kérdés, mennyire elegáns
az a megoldás...
Cece