A project that I'm working on right now required me to migrate data from the existing database to the new database and database structure. Since the application is built on top of Symfony2, I decided to write a Command that would take care of the migration. I ran into an issue though: Doctrine2 insisted on creating new IDs where I wanted to keep the old one. The solution turned out to be really simple.

The actual code for the Command is only a few lines long - it just turns off the "AUTO" strategy for each of your entities, making it ignore any IDs you have set on the entity already.

Silex is great for its simplicity, however for larger projects you probably want to use some ORM like Doctrine but there's build-in service provider only for Doctrine DBAL and not ORM.

He breaks it up into five smaller steps, each with code samples to help clarify:

• Doctrine 2 ORM Service Provider
• Create your entity classes
• Mind Doctrine DBAL and Doctrine ORM versions
• Doctrine CLI
• Working with Doctrine ORM

With the new modular infrastructure in Zend Framework 2, one of the most common questions will indoubitably be how to share a database connection across modules. Here's a quick explanation of how to share your database connection across multiple modules in a way that can even allow you to use a single connection between ZendDb, Doctrine2, and possibly even other database libraries / ORMs.

He includes the code in the post to configure this application-wide database resource, a "masterdb_pdo" that uses a MySQL backend. This configuration is used to set up the connection in a dependency injection container for later (globalish) use. He also mentions something similar about sharing Doctrine connections with the ZendDb components (using the same DI container approach).

Zend Framework 2 is getting close to release, and among the changes are new ways to handle dependency injection, and new ways to work with third-party code as modules. Rob "Akrabat" Allen has updated his iconic Getting Started with Zend Framework tutorial for ZF2, and it's a great place to start. After working through that tutorial, the next thing I wanted to do was figure out how to get the Doctrine 2 ORM up and running. This article shows how to set up and use Doctrine 2 in Zend Framework 2, by extending Rob's Getting Started tutorial to use Doctrine instead of Zend_Db.

Using Rob's example as a starting point, he shows how to install the Doctrine modules, update the "Album" model and controller to use Doctrine instead of Zend_Db and create the entity for the Albums.

The easy ways is doing it with Javascript and just show/hide the correct fieldsets when needed. The downside with this approach is that the data is only saved and validated once at the end. So if the user reloads the page the entered information is gone. The other way is to have every Step in the Wizard being a seperate form and validate the data based on what step you are on and save the necessary fields.

For his method, he created a Manager class with a StepInterface that returns the correct field names, forms and template information to render. The interface code is included in the post as well as an example of it in use setting up the wizard object, making a report and getting the correct step information from the wizard.

Phar is a php extensions that provides the means for distributing code as a single archive, that does not have to be extracted to a folder before usage. The concept is similar to JVM Jars: each archive becomes a virtual directory where files can be accessed. However, the virtual folder is not limited to class loading, but you can open and read internal files as if it were decompresse into a directory.

He includes a brief "hello world" example of packaging up a script into a phar archive and executing it via PHP. He also shows how easy it is to create an archive from current code, making an archive containing the latest Doctrine 2 release for simple inclusion. Phars also allow compression and hashing but has issues with resource management and access external files.

The recently released Doctrine 2 presents significant advantages over its 1.X predecessor, advantages which are even more pronounced when compared to the Zend Framework's default database solution, namely the Zend_Db component. [...] When running unit tests which vet various aspects of your database you'll want to setup (create) and teardown (destroy) the test database, ensuring that a pristine and repeatable version of the database is available to each test.

He includes an example of using the SchemaTool class (of Doctrine) to drop and recreate the schema from scratch with the end result of a clean working copy, ready to test from. He also includes an example of how to initialize the database with some default information using the PHPUnit database connection and a default set of fixtures (defined in YAML).

In fact DBAL isn't a pure database abstraction layer. It's built over PDO. It's a set of PHP classes we can use that gives us features not available with 'pure' PDO. If we use Doctrine2 we're using DBAL behind the scene, but we don't need to use Doctrine2 to use DBAL. We can use DBAL as a database abstraction layer without any ORM. Obiously this extra PHP layer over our PDO extension needs to pay a fee. I will have a look to this fee in this post.

He includes a few simple benchmarking scripts that compare similar operations done by either, including memory usage and execution time. PDO comes out on top, obviously, because it's an extension versus a set of PHP libraries that need to be included in the application. He does include examples of a few things he likes that DBAL does that PDO doesn't by default - a transactional mode, type conversion, a simpler binding interface and the ability to nest transactions.

Nowadays developing web applications usually requires a flexible process due to changing business logic, shifting priorities or new insights. Besides choosing the right methodology this also requires designing the application in such a way that this flexibility can be achieved. [...] In this article I will show how to implement a specific case using Doctrine 2. Full code accompanying this article can be found on GitHub.

He starts by describing the entities (User/TimeSheet/TimeSheetStatusChange) and how they're defined in Doctrine objects. He modifies them to build in some business-level restrictions like "status changes are only allowed in a certain order". He shows that the domain models presented are about more than just working with the database tables. They enforce rules that effect the flow of the application as well.

The most important thing you should provide with your re-usable bundles is unit tests set. Lately I solved two major cases which Symfony2 hasn't got out of the box: testing services, defined in Dependency Injection Container and running model tests with fixtures in fully isolated environment.

He includes code snippets for both solutions - a BaseTestClass for working with dependency injection testing and a ModelTestCase class that, in the setUp(), loads in the required fixtures so the test can be completely isolated.