Doctrine 2 BETA1 Released

I was waiting a long time for this moment! Doctrine 2 is getting better each version! I am using trunk version and I can say it's almost done!

Good work!!

Congratulations to the team! You've been making great improvements. Doctrine is a great framework and precisely what the PHP world needs!

Unfortunately I haven't had the time to play with it lately but the alpha1 release is proving itself well in a heavy production environment!

Thanks for an awesome product!

Kindest regards

I've been following the development closely for a while now. Thank you for all your hard work - Doctrine 2 is really a breakthrough technology. Warm regards.

That's great news guys.

One thing bothers me though: Like you recommend on your documentations, all my projects use svn:externals to download doctrine. This is cool, as i was able to easily upgrade the doctrine tag after new releases. With git I am kind of lost now..

Hello Russel,

Github offers an SVN Export of all Github Projects for several weeks now, see here how it works:

http://github.com/blog/626-announcing-svn-support

Not sure I agree with the change "Selecting Partial Objects", it seems that this would be better handled by hydration modes as that is what it seems to be doing. So now, SELECT queries will also be HYDRATE_ARRAY rather than HYDRATE_RECORD unless using that special syntax... Not sure, but definitely seems going backwards and causing more trouble than needed for something that should just be a flag? Like unnecessary semantic complications.

Any feedback would be greatly appreciated. As Doctrine 2 is definitely eagerly awaited! On that note, any idea about PHP 5.3 adoption? Would be really nice to see an article so open source project developers can get a feel on whether they should start adoption yet.

As always, keep up the great work!

Hi,

no, partial objects are not a "hydration mode". What you're suggesting would mean that "u.name" has a different meaning in different hydration modes, which is not desired.

Maybe it's a bit tricky to understand the semantic difference. As a start, ignore the hydration modes. Now in a query like "select u.name ..." "u.name" always means the same thing: select the values of the name property, not the object. The object would be just "u".

So, regardless of hydration modes, when you look at a DQL query, "u" always means object, "u.foo" always means scalar value of an object field, "count(u.foo)" or any other function always means a scalar value and "partial u.{foo}" always means a partial object. Irrespective of hydration.

Hydration mode is the second step. It is a choice how you want these 2 (they're only two! (partial) objects and scalar values!) types of result elements are actually represented in the result. This does not change their meaning in the DQL query! We do not want different meanings for the same syntax in a DQL query. With your suggestion, "u.foo" in a DQL query could either be a scalar field value or a field on a partial object.

The new syntax for partial objects is much clearer and now you can select object fields as scalar values which was not possible before, we would have needed to introduce some special function like: scalar(u.foo) ! That, in addition to the ambiguity of what "u.foo" itself means in a DQL query.

Hope that helps a bit to understand our reasoning.

Just forget about the hydration modes for a moment :) DQL speaks in objects. Hydration modes can just give you a different "view" of them.

@beberlei - Thanks for the link.

My projects are all svn based so I'm very interested in being able to use svn:externals as well. Will you continue to keep your own svn repository up or do you suggesting trying the method outlined in the link?

Hi,

the svn tag for BETA1 is now available, if that helps:

http://svn.doctrine-project.org/tags/2.0.0-BETA1/

Excellent works guys!.

Okay mate. That makes a bit more sense, is there any stuff in the documentation about this which I can look at for further reading? As that would be great :-)

That's great news.

Just what the PHP world needs! Thanks very much.

Good work!!

That's great news

I am already using alpha version with zend framework now it becomes beta. Its really awessome.

I am also waiting for its stable version.

Thanks Raju

amazing PHP project!!!

Thank you guys

Good work! hope i can integrate at least the rc version in my new projects. keep on your fantastic work :)

Good work! I hope Doctrine 2.0 will be a part of Symfony 2.0.

Best PHP project at the moment.

hey!

first of all. doctrine 1.2 was great and doctrine 2 looks fabulous! for sure the best orm for php that i know. well.. actually the only one i've really looked at since zend_db what i normally use in php is not really an ormapper and more an implementation of the active record pattern. and that usually sucks in bigger projects...

well, i'm just wondering, why is doctrine all written in php. wouldn't it be faster if written in c++ and used as a php module.. maybe even integrated in PHP6? i mean.. it's lots of codelines.. and most software would use it over and over again.. would just be nice to have it compiled and highly performant fitted to the underlying operating system. even if i'm using almost every class from the zend framework and lots of other libraries.. i'm still thinking php is an oversized template engine (ok.. not really that bad and i would still preferer it to all other scripting languages for webprogramming just because it can be used on every cheap server and it's on the same technological level than ruby and phyton..) but i'm really convinced it would be better to use more good c++ libraries in the background than have giant php libraries .. an or-mapper directly integrated in PHP6.. that's my dream!!!... can someone explain me why nobody is doing it.. or are there some peoploe who would help me to port doctrine to c++ as a php module for pecl??.. maybe under the doctrine project?.. if we're good enough maybe it will be integrated in a php version in the future.. i'm sure i couldn't do it alone.. i'm not a real c++ crack anyways.. and i know you guys allready put a lot of work in writing this stuff in php which is usually a bit easier that c++.. so i'm sure this would be a lot of hard hard work... well i'm still hoping someone will do it..

cheers

When thinking a bit more about it, I'm sure you can find the answers yourself :) Here are some points that come to mind immediately:

1) It would be much more difficult to implement in C/C++, probably at least doubling the code size. 2) Very few people that develop or use Doctrine know C or C++ very well. 3) The performance of the Doctrine PHP code, especially D2, is fast enough for the majority of sites and use-cases. And everything is always getting faster, the hardware, PHP, Doctrine itself, ... 4) As a consequence of 2) and the fact that its then probably distributed in binary form will make debugging for users extremely hard. They can no longer just look at the Doctrine code. 5) There is already HipHip for PHP from facebook if you want to convert the PHP to C++. 6) As a consequence of being a C/C++ extension it is harder to install and use and any people who can not just install any custom php extension they want could not use it.

I could probably think of more reasons the longer I think about it but these should already be enough to show that its a bad idea.

ps. are you actually having serious performance problems that are proven to originate from the Doctrine PHP code itself (not I/O, network or anything else)? If so, please share some info and numbers on the developer mailing list!