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.
Related
In my Syfmony 4.1 project, I'm using Custom Annotations to apply some meta data to some Value Objects. I'm following the Doctrine Annotation Documentation, which (I think) is assuming that you're using Doctrine as a stand alone package.
However, it seems to me that Symfony is handing some of the Annotation Setup for you. As an example, the documentation talks about using its own autoloading mechanism rather than the one provided by PHP / Composer. Symfony seems to handle this automatically.
The documentation talks about Annotation Readers and recommends caching your Annotations with either a FileCacheReader or Doctrine AppCache. I'm assuming that Symfony is using one of these mechanisms (or it's own caching mechanism) to cache Symfony's built in Annotations.
My question is this: Does Symofny automatically handle the caching of Custom Annotations, or do I need to cache them manually?
Symfony takes care the caching of doctrine annotations through the doctrine bundle configuration:
doctrine:
orm:
metadata_cache_driver: array #this is the option to configure
query_cache_driver: array
result_cache_driver: array
The metadata_cache_driver options define the cache driver that symfony uses to cache the annotations.
All you have to do is to configure this option properly to have your annotations cached.
More on how to properly configure the cache driver options in documentation.
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.
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
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.