What is difference between Doctrine 1.2 and 2.0, how to choose between them.
Doctrine 2
it's the recommendend version
ships with symfony 2.0
faster than 1.2
no magic methods
uses entity manager (datamapper like)
components are loosely coupled
requires PHP 5.3 (uses namespaces)
relative new project
Doctrine 1.2
easier to learn
works with php < 5.3
ships with symfony 1.3 / 1.4
magic methods (ActiveRecord like)
mature and tested project
less typing
Doctrine 2.0
$user = new User;
$user->setName('Mr.Right');
$em->persist($user);
$em->flush();
Doctrine 1.2
$user = new User;
$user->setName('Mr.Right');
$user->save();
To summarize, imho Doctrine 2.0 has a steeper learning curve even if it
performs better (clever use of transactions). I find ActiveRecord persistence model and magic methods rather clumsy so I'll go with the 2.0, but this is my personal opinion,
Doctrine 1.2 is still very good (expecially with small projects where the 2.0 could be overkill)
see also
Doctrine 2.0 ready for use?
Datamapper vs ActiveRecord
Related
I am using MongoDB as a DB storage, thus I should use DoctrineMongoDBBundle to use Doctrine in my Symfony application. DoctrineBundle is installed by default with new Symfony installation, but I can safety remove it and it seems not to affect my work with Doctrine.
Should I really remove this bundle? Is it completely useless in case of using MongoDB, or I miss something, and I will need this bundle for some reason in the future?
Doctrine can mean a few things. Usually it's by default understood as Doctrine ORM. But in your case you want to use Doctrine MongoDB ODM.
DoctrineBundle is a Symfony intergration for Doctrine ORM and DBAL
DoctrineMongoDBBundle is a Symfony integration for Doctrine MongoDB ODM
Doctrine ORM and Doctrine MongoDB ODM are two separate, independent projects.
Therefore you can remove DoctrineBundle if you don't use relational databases.
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).
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 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.
I am currently developing a system on a server running PHP version 5.1.6 thus I am forced to use Symfony 1.1 in the current environment.
I am planning to migrate the application from 1.1 to 1.2 in the somewhat near future and I was wondering if anyone has any experience with this?
I have attempted to migrate a system from 1.0 to 1.1 and that was a major pain in the rear.
How has it been for anyone out there migrating from Symfony 1.1 to 1.2?
My 2 cents is that it all depends on how many forms you have in your application, that was by far the most painful part. Symfony 1.2 has an entirely new form system.
you can always do compac10 = true or whatever ...to make your old code compatible,..
Symfony 1.2 does have many new useful widgets,..and propel 1.3 is a significant improvement, fixed some bugs that I was actually running into.
It should be fairly easy if you didn't use custom SQL queries with Propel (i.e. manual hydratation) as Propel 1.3 switches to PDO.
I migrated an 1.1 app to 1.2 and I had nothing to do except running the automatic upgrade script.
For me, migration to 1.2 was fairly painless. The upgrade script should do all hard work.
The biggest problem will be migrating to propel 1.3 if you have used 1.2 ( default with symfony 1.0.x and 1.1.x). If you were using propel 1.3 before ( with sfPropelPlugin) or Doctrine there shouldn't be any problems.
Another one will be porting admin generated modules to new admin generator, but in 1.2 the oldones still work for now.
Those listed above are the biggest changes in 1.2.
And I love 1.2 for it has lots of new cool stuff ( REST routing, new admin generator, some minor fixes etc.)