On the NetTuts site there's a tutorial posted helping you get familiar with Doctrine 2 (the ORM) and how to integrate it with a Laravel 5 application via a simple service provider.

As a PHP developer, you might have come across the term ORM. ORM is a way to work with databases in the same way you work with classes and objects. If you were to delve deeper into how web applications are designed and built, after doing some exploring in their ORM you would find two well-known patterns: Active Record and Data Mapper.

[...] With Data Mapper the in-memory objects needn’t know that there is even a database present. They need no SQL interface code or knowledge of the database schema. One such solution is Doctrine.

The tutorial walks you through some of the basic concepts in using the Doctrine 2 ORM including Entities and Repositories. Also included is how to pull it in via Composer and update your Laravel configuration to use this bridge library for integrating it into your current application. Code examples are included showing you how to build out an entity, repository and a validator class for a basic blog post.

On the Vertabelo blog Patrycja Dybka has put together a side-by-side comparison of Doctrine 2 vs Propel 2, two of the more popular PHP-based ORM tools, largely popular in the Symfony communities.

When you start working with data in an application, you may need to use an object-relational mapper (ORM), a layer between the database and application. For PHP the two most frequently used ORM's are Doctrine and Propel. That's why I decided to compare the main features of Doctrine in version 2.4.7 and Propel in version 2.0.

She doesn't try to pick a "winner" but instead talks about the features of each and the main difference between the two (ActiveRecord vs DataMapper patterns). The remainder of the post is the side-by-side listing of the feature of each including:

• Install method(s)
• Model structure definition types
• Mappings
• Supported databases

There's also some examples in the list of code to define tables, perform basic CRUD (create, read, update & delete) operations, basic queries and custom data types each includes. It's a good comprehensive list if you're trying to make a decision between the two or even just looking to find out what each has to offer.

In this tutorial to the stfalcon.com site Sasha Lensky talks about some things you can do to help boost the performance of your Symfony2 application with a few tweaks in how Doctrine is used.

I have been trying to write this article for a long time, but just couldn’t get around. Finally, I pulled myself together and did it. So, what will we discus ... I will share some techniques about working with Doctrine2 ORM, which will help to improve the site performance on Symfony2 (precisely any site that uses Doctrine2 ORM). I have created a project and put it on GitHub as a visual guide, so anyone can test my words in action now.

He shares five tips and includes code examples and results (based on the Profiler toolbar) for each:

• Downloading all necessary connections
• Updating multiple entities by request
• Hydration waiver
• Using Reference Proxies
• Using Symfony Profiler Toolbar

That final tip about the Profiler toolbar is actually one used in the rest of the examples too, showing how to get that other information from the tool.

In this latest post to his site Stefan Koopmanschap shares a solution he's found to migrating data with Doctrine2 from an existing structure.

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.

Martin Sikora has shared some of his experience with setting up a Silex instance to work with Doctrine2 in a new post to his blog. The popular microframework comes with a built-in Doctrine service provider, so integration isn't overly difficult.

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

Evan Coury has a new post to his site about a handy method for sharing database connections across modules in a Zend Framework application.

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).

Jason Grimes has posted a new tutorial to his blog about integrating Zend Framework 2 with Doctrine, the powerful (and popular) ORM tool for PHP. In his example, he shows how to use them to store the album information from Rob's tutorial.

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.

Henrik Bjørnskov has a new post with a technique you can use to combine Symfony2 and Doctrine2 to create a multi-step form (a wizard) without having to worry about lost user information between steps.

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.

On DZone.com today Giorgio Sironi has a new post looking at an interesting, if seldom used, feature of recent PHP releases - packaging applications with phar archives.

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.

New on PHPBuilder.com today is a tutorial showing you how to use set up and tear down methods in PHPUnit unit tests to work with a Doctrine 2 database, making it simpler to run self-contained testing.

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).