Hi Benjamin, Thanks for the insight into your work on Zend_Entity. The reason I believed that Doctrine used getters and setters for hydration was that the documentation encouraged making the members private (so I assumed that Doctrine would not be able to properly set the values without accessors).
I'll have to investigate your ArticleProperty suggestion to see if it would work for my purposes...it is possible that it would solve my issues. I understand that a full featured ORM is very difficult to write well, and appreciate your contributions to Doctrine. I know that it is quite complicated internally and has taken much effort. I imagine that the DBAL has also contributed to the length of time required to make Doctine (something that is already done in ZF). My intentions are not to dismiss Doctrine, but rather to explore in greater depth the pro's vs con's of a Zend component and get the communities opinions on both sides. Of course we should avoid duplication of effort where possible and feasible...as long as the consensus is that Doctrine2 should be favored over a native Zend ORM and it is a native component is not worth the effort. On Tue, Nov 16, 2010 at 3:53 PM, Benjamin Eberlei <[email protected]>wrote: > > Hey Nick, > > Doctrine does not rely on getters and setters for hydration. It only uses > reflection to set and get the values. That is why we cannot implement your > requested support for dynamic fields. > > However the functionality you want from Doctrine 2 exists in 2.0 already > and is planned to be hugely optimized for 2.1, but in a totally different > way that you requested in that ticket I closed. For an Article entity in > your CMS you could add a collection of ArticleProperty instances that > define your dynamic data. Dynamic data is in a second database table > anyways. Just define it as collection of attributes and there you go. > > "It would simply provide ORM 'out of the box'" is a statement easily made, > but developing an ORM takes lots of time. I already had invested about half > a year into Zend Entity before dropping it and am now working on Doctrine 2 > for over a year (but development started about 2 and a half years ago). I > doubt you will find enough man-power to write an ORM that covers 80% of the > use-cases in less than a year. ORMs are not called the vietnam of computer > science for a reason, they are either not simple (and therefore take lots > of careful planning and development) or they are simple and just serve > 50-60% of use-cases with a database. > > greetings, > Benjamin > > On Tue, 16 Nov 2010 15:34:17 -0700, Nick Daugherty > <[email protected]> wrote: > > Hi Jurian, > > > > I'm not sure if Benjamin's reasons for stopping were 'very good'...to me > it > > sounds like it came down to him not having enough time to flesh > everything > > out and get it as functional as Doctrine, rather than real reasons for > > excluding it from Zend. If we find additional interest in the project, > it > > should be revisited. > > > > Just to be clear...Zend\Db would not be changed in any way, the new ORM > > would simply be a separate layer that leveraged it's power. > > > > And of course Doctrine integration should still exist...the Zend_Entity > (or > > whatever it turned out to be) would be an option for Developers...nobody > > would be forced to use it. It would simply provide ORM 'out of the box' > in > > a > > native Zend Framework implementation. Those that preferred Doctrine > would > > be > > free to use that. > > > > I'm not sure why you say an ORM is 'too much'...if ORM is too much, do > you > > consider MVC to be 'too much'? It controls how your entire application > is > > written, not just the persistence. > > > > On Tue, Nov 16, 2010 at 3:20 PM, Jurian Sluiman > > <[email protected]>wrote: > > > >> On Tuesday 16 Nov 2010 22:45:42 Nick Daugherty wrote: > >> > Regardless, I think Zend is important enough to have it's own ORM. If > >> > it > >> > had a performant and above all, easy to use, ORM, it could be THE > >> > killer > >> > framework. Right now, Symfony is easily coupled with Doctrine (and > >> > Doctrine requires parts of it) and seems to be gaining momentum. ORM > >> would > >> > definitely be one of the killer components of the ZF and > significantly > >> > lower the barrier to entry for new developers. > >> > >> A complete ORM for ZF is way too much. It is tried by Benjamin and this > >> process stopped because of some very good reasons [1]. > >> > >> The more or less low-level implementation of Zend\Db to use it as an > ORM > >> is > >> just perfect I think. When someone wants a more specific tool, Doctrine > >> is > >> the > >> right way to go. > >> Therefore my suggestion is to keep Zend\Db as it is now (in its > >> functionality) > >> and make proper tools to integrate Doctrine2 into ZF2 really easy. Then > a > >> developer can choose which db layer s/he wants. > >> > >> Regards, Jurian > >> > >> [1] http://www.mail-archive.com/[email protected]/msg25412.html > >> -- > >> Jurian Sluiman > >> Soflomo - http://soflomo.com > >> >
