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 >>
