In a new post on his Medium.com site Romans Malinovskis has posted an objective comparison of ORM/DBAL libraries based on his own list. It includes several different libraries from all around the community including Doctrine, Eloquent, Cake ORM and Agile Data.

For many of us, developers, pattern of accessing external data (SQL) is a thing of preference. We get used to different syntaxes and subjectively endorse it. By looking past the individual preferences, I wanted to create a “comparison criteria” that would help PHP community to objectively evaluate data persistence frameworks based on features. As I looked around I haven’t found anything, so I started to work on my own list:

https://socialcompare.com/en/comparison/php-data-access-libraries-orm-activerecord-persistence. I welcome my readers to help me populate and use the table. In this article I explain various features which I’ve used as comparison criteria.

The (lengthy) post is divided up into sections for each of the criteria including:

• Sections and Scope
• Support of Persistence Engines
• Criteria, Scope, Condition
• Query Building
• Single-record operations
• Relations and References

...just to name a few. Each section comes with an explanation of what it is in a library-agnostic way and code examples where relevant. Be sure to check out both the table and the rest of the post for the full details.

Robert Basic has written up a quick post to his site sharing details on how you can use Doctrine's DBAL with Zend Expressive without having to use the entire Doctrine ORM. DBAL is Doctrine's abstraction layer that makes it easier to work with your database at a higher level than writing manual SQL statements.

The database abstraction and access layer — Doctrine DBAL — which I prefer over other abstraction layers like Zend DB. My good friend James, aka Asgrim, has written already how to integrate Zend Expressive and Doctrine ORM.

But what if want to use only the DBAL with Zend Expressive, and not the entire ORM? It’s pretty easy as all we need to do is write one short factory that will create the database connection using the connection parameters we provide to it.

He includes the code snippet you'll need to define a "ConnectionFactory" to set up the connection and the configuration needed to allow it to connect to the database. He then shows how to set up the DI container with the new container factory as a dependency and use it by pulling the "db" object out of the container.

Ross Tuck has submitted a new article he's posted about persisting value objects in the popular PHP database storage and object mapping library, Doctrine. Value objects are immutable objects that " follow value semantics rather than reference semantics".

I’ve been using more and more Value Objects in my applications over the last year, primarily with Doctrine ORM. Value Objects are an extremely powerful technique and I’ve been impressed with how much they can clean up a codebase. One of the main questions I’ve had when starting with Value Objects is how to persist them with Doctrine. This post attempts to create a reference for all the different persistence techniques I’ve seen so far.

You'll need to be familiar with Value Objects and Doctrine before starting (it's not an "intro to Doctrine" article). His example sets up an "IPRange" and an "IPAddress" that are stored in a "Server" instance. He talks about mapping the value object to the database and the getter/setter to do the work. He also touches on DBAL types, working with multiple columns in the entity and the "promised land" of embeddables. He finishes off the post looking at collections of entities and some of the other options to what he's shown (including serialization).

The Doctrine project has posted an update about the work being done in collaboration with and to help its performance with HHVM (the HipHop VM from Facebook) and talking about their future plans.

Facebook has been pushing HHVM alot lately, helping open source projects to get their test-suite running 100%. For Doctrine HHVM is particularly interesting, because of the performance gains that the complex PHP algorithms inside ORM would probably get. From my current feeling Doctrine will be the PHP open-source project getting the most gain from running on HHVM. However with the tests not yet passing on the ORM, we can only imagine how big that performance improvement will be.

One of their goals is to be able to run DBAL/ORM on HHVM with 100% passing tests. So far they've been working on Common project functionality and have three as fully supported under HHVM - Collections, Inflector and Lexer. Work is still being done on other parts of the codebase, with the ORM and DBAL being the lion's share of the job.

Gonzalo Ayuso has a second post in his series looking at using the Symfony2 dependency injection container with Doctrine functionality. In his previous post he talked about sharing PDO connections via the DIC. In this latest one it's focused on the sharing of DBALs from Doctrine.

OK. We can handle PDOs connections inside a Symfony2 application, but what happens if we prefer DBAL. As we know DBAL is built over PDO and adds a set of “extra” features to our database connection. It’s something like PDO with steroids.

He includes the (PHP) configuration to set up the DBAL and the YAML definition to set it up in the DIC's configuration. As an update to the post, he also points out a bundle for Symfony2 that lets Doctrine do this natively - check out this documentation on github.

In this new post to his blog, Gonzalo Ayuso compares two technologies that can make working with databases in your applications simpler - PDO and the Doctrine2 DBAL layer.

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.

On his blog today Sameer Borate has a new post looking at using Doctrine DBAL to make schemas rather than having to make them by hand each time (can be very useful for reloads with fixtures).

A tedious task during web development is that of database schema creation. A schema containing a few tables comprising of a small set of rows is quick, while that containing dozens of tables and large numbers of columns is a tedious process. I usually resort to a small php script with some regular expression tossed in to automatically create a schema from a text file definition. But that is a little buggy as I’ve to manually add the indexes and other small things. Now that Doctrine has released a DBAL library, this will provide a nice ability to automatically create sql schemas.

He introduces the DBAL abstraction layer and includes a basic script to create a schema for a MySQL database, manually adding the columns and setting up things like primary keys and foreign key constraints. He also includes the SQL statements that it will generate and execute on your Doctrine-based connection.

David Coallier has posted about a database abstraction layer that he's been developing for PHP 5.2.x only systems and wants some opinions on his methods:

I made a very light DBAL that uses PHP5.2.x only (Since many people seem to want that) and it has the exact same DSN syntax as MDB2 for now and the query method are also called the same (No API Changes). [...] The main goal of the DBAL is to have a very effective and light way of switching RDBMS but also the possibility to change your DBAL to something more "0feature complete" as such as MDB2.

He includes the list of query method names and the types of databases that he wants it to support (as well as mentioning the fact that it would be unit tested for reliability).

David Coallier has posted about a database abstraction layer that he's been developing for PHP 5.2.x only systems and wants some opinions on his methods:

I made a very light DBAL that uses PHP5.2.x only (Since many people seem to want that) and it has the exact same DSN syntax as MDB2 for now and the query method are also called the same (No API Changes). [...] The main goal of the DBAL is to have a very effective and light way of switching RDBMS but also the possibility to change your DBAL to something more "0feature complete" as such as MDB2.

He includes the list of query method names and the types of databases that he wants it to support (as well as mentioning the fact that it would be unit tested for reliability).