I am in the early stages of rearchitecting my company's application. The app is currently running on symfony 1.2, and I used the default ORM at the time, Propel.
Symfony has since updated to 1.4 and switched default ORM to Doctrine.
From my understanding, each ORM excels at particular types of database structures. Is this true or is one far and away better than the other?
Are there any good methods to test which ORM would be best in my situation in a test environment using my schema (i.e.- set up dual, identical sites and run tests)?
Here's a slightly newer comparison than the 2008 one: Doctrine vs Propel: 2009 update. There's also a (slightly Propel focussed) benchmarking exercise here.
In reality, the community around the frameworks is as important as the technical differences. I'm using Doctrine as I've been able to find much more relevant support information and examples. The traffic to the Symfony website suggests that that Doctrine is becoming the most popular choice, so I expect the Symfony/Doctrine community to continue to grow.
Symfony 1.4 default ORM is currently Doctrine 1.2.
I don't is there's any performance difference between Propel and Doctrine 1.2 but you can also use Doctrine 2.0 with this version of Symfony : done here
Doctrine 2 is a complete rewrite of Doctrine, seems to be faster and supports ODM like MongoDB.
Related
I am developing a web application using Zend Framework 2 and Doctrine 2. I'm new to Doctrine 2 in general and Migrations in particular. I was wondering if there are any recommended best practices in using this. Some specific things I'm looking for:
A recommended workflow from development to deployment?
Do you include pre-populating data in migrations?
How to handle reverting to a previous version if migration fails.
Many thanks!
Doctrine has own library for migrations, that includes also Symfony bundle.
For Zend there probably is some bundle as well (maybe seek on Github a bit more)
As for your specific questions:
Nothing special. Basic workflow is nicely described in Symfony bundle documentation. We use it in pretty same way even in a different framework.
Yes, so every developer has fully operational system. For tests we use data-fixtures with minimal required data only.
It's managed by this package itself.
The Doctrine ORM module for ZF2 (DoctrineORMModule) has built-in support for Doctrine ORM migrations. There's a very brief blurb in the documentation about how to configure it. You can then access the migration commands (generate, migrate, etc) through the CLI interface that module provides (vendor/bin/doctrine-module)
As for my personal workflow I generally put initialization or pre-population data - the stuff you initially seed a new installation with - into database fixtures (which Doctrine ORM also supports and there is a ZF2 module for).
Is the Doctrine Migrations project compatible with Doctrine MongoDB?
It isn't clear to me from searching and looking at the Doctrine Migrations project whether it is compatible with ODM solutions (e.g. MongoDB) as well as ORM solutions.
If it is, can anyone suggest examples or articles on how to use the two together?
If it isn't, are there reasonable alternatives?
Question Background:
I understand, marginally, the different approaches to migrating a document's data from one version of the document to another and the pros and cons of each.
I am leaning towards possibly implementing a hybrid approach of gradual schema changes and migration scripts as suggested here. Leveraging the functionality within Doctrine's MongoDB library written about by Jonathan Wage in his post: Doctrine MongoDB ODM Schema Migrations.
Even with that, I need to find some way of creating a migration script or performing the data migration, and Doctrine Migrations seemed like a good first choice.
As an aside, another user warns against using the approach Jonathan Wage presents above for migrating data and instead running commands (JavaScript?) directly against the database.
Despite doctrine-migrations is not compabible with MongoDB ODM (it only supports DBAL) you can bet for the alternative mongo-based migration components made by 3rd party teams.
It was firstly developed here https://github.com/antimattr/mongodb-migrations
but after it has been abandoned the project continues here https://github.com/doesntmattr/mongodb-migrations
Ufortunately, it isn't compatible with ODM. It supports ORM only.
Kohana 3.0 used to have Sprig, Jelly, etc. alongside with its default ORM system. As far as I understand, Kohana 3.1 is not compatible with Sprig and Jelly and its default ORM is still in development. What to use for ORM in Kohana 3.1 then?
Take a look at Leap ORM for Kohana. You can download it off github at https://github.com/spadefoot/kohana-orm-leap
This ORM is designed to work with Kohana 3.0.X, Kohana 3.1.X, and Kohana 3.2. It works with all major databases (including MySQL, MariaDB, PostgresSQL, MS SQL, DB2, Oracle, Firebird, and Sqlite) unlike the other Kohana ORMs that I have seen. Expanding the ORM is extremely easy whereas Kohana's default ORM cannot be adapted to work with such databases without a lot of work.
It is pretty well documented. Unlike other ORMs for Kohana that I have seen, it can handle composite primary keys and can use more than integers as primary keys (e.g. strings). It also give you the flexibility to switch the database driver from the standard PHP extensions to PDO using a simple config file.
You can find 3.1 modules at Github:
Jelly for 3.1 (unofficial fork, Banks and Jonathan Geiger have no time for development)
Sprig branch for 3.1
Have you checked out PHP ActiveRecord? It is an ActiveRecord style ORM with validations, realtionships, eager loading, etc.
I strongly suggest you to use:
http://www.doctrine-project.org/projects/orm
I have used both the default ORM in Kohana 3.0 (should be similar to the one in 3.1) and the doctrine ORM in big projects.
Doctrine is great. Everything you wan't is there. Even for very special and tricky cases. If you use the default Kohana 3 ORM you will end up extending it because it is to simple.
The configuration part in Doctrine can be a little scary because there are a lot of options. In the long run it is really worth it though :)
I'm using Zend Framework and I feel that I need a good ORM to work with. I don't know much of Zend Framework, I just know how to do the basics. I expect to work together with both Doctrine and Zend Framework
But to sget started, I'm going to try a simple Doctrine project (no ZF) to get used to the application. Then I'll try to integrate it in ZF
Which version of Doctrine do I start learning? Does Doctrine have a good integration with ZF?
Besides,
Is there any recent site for Doctrine learning? I just can't find the sandbox version to follow the Doctrine documentation. If anyone knows of any tutorial on how to get started with doctrine only first, please let me know
I've done projects with zend framework and doctrine. They play pretty nice together.
I followed this tutorial and it worked well.
But honestly I don't use doctrine on anything but the largest sites. I've switched over to RedBean. Zero configuration autodiscovery, and the ability to freeze data models when you are done for maximum performance.
You should really try it out, it is so simple its stupid. It is really one of the best ORM's ive ever used. EVER. Try it.
I am personally using Doctrine 1.2
and i followed the Zendcasts.com "more than 5 casts about doctrine" & same Byron's tuts
both of them is good
Update :
1- http://www.zendcasts.com/deep-integration-between-zend-and-doctrine-1-2/2010/01/ has the sample code
2- http://www.doctrine-project.org/projects/orm/1.2/download/1.2.3 has the doctrine framework if you need to download it alone
I've found Doctrine2 reasonable stable, although it's still in beta. It seems most of the other PHP 'ORM' libraries (Doctrine 1.2 included) are Active Record, while Doctrine2 is a Data Mapper. In my opinion, you can put together a relatively simple Active Record using Zend's native Db_Table, so that makes Doctrine 1.2 less appealing (at least to me).
I've used this answer about integrating Doctrine2 and Zend Framework.
I agree with Byron, and have only used Doctrine2 on select projects.
[As an aside, I've noticed RedBean in the past, and have wanted to try it - from what I've seen it's certainly worth taking a look.]
Doctrine 2 is in beta and requires PHP5.3 as it fully utilizes Namespaces. If you cannot use PHP5.3 in your project, you cannot use Doctrine 2.
Apart from that, there has been a number of architectural changes in Doctrine 2 that make it much more attractive than Doctrine < 2, mainly
using DataMapper instead of ActiveRecord
promotes DI over static calls
faster and less memory-intensive
revolves around Entities and DDD
uses "Annotations"
See
http://architects.dzone.com/articles/doctrine-1-doctrine-2
http://www.slideshare.net/jwage/doctrine-2-not-the-same-old-php-orm
I'm working on a small project (some mark tracking software for a school subject department - PHP frontend with a sqlite DB) and have decided to use ORM.
I've taken a look at RedBeanPHP but it seemed a bit too limited for my liking. As such, I've decided to give Doctrine a go.
My only prior experience with ORM is LINQ to SQL in .NET. Anyway, I was wondering if I should get started with Doctrine 2.0 (which is in beta at the moment) or if I should take sometime to learn 1.2.
I'm looking for feedback from those who are comfortable with both, and more importantly, I'd like to know how complete the Doctrine 2.0 documentation is. Is there enough information on the website for somebody new to Doctrine (and quite new to ORM) to get up and running with 2.0 or is the documentation for the new version still quite lacking?
Doctrine 2 is a DataMapper ORM whereas 1.2 is Active Record. I would go with 2.0; the documentation is great
The Doctrine2 documentation is quite good already. I'd start with the reference.
I've been developing with Doctrine2 for a few months now, and have had no issues. I'll be going into production with it soon, and am pretty confident.
2.0's DataMapper pattern is really superior to the 1.2/ActiveRecord model. Very flexible, and possible more performant. If you're starting development today, I think it's very likely the best way to go.