Simon Holywell has a new post to his site about a project that aims to be a minimalist ORM library and make it easier to built queries on the fly for your applications (and is installable via Composer) - the Idorm + Paris combination.

Idiorm is a PHP ORM that eschews complexity and deliberately remains lightweight with support for PHP5.2+. [...] However, having said this, Idiorm is very powerful and it makes most of the queries PHP applications require pain free. Some of these features include fluent query building, multiple connection support and result sets for easy record manipulation. Paris sits on top of Idiorm to provide a simplified active record implementation based upon the same minimalist philosophy.

He includes examples in the post of both queries with Idiorm - simple things like creating and finding records - and using Paris to make models out of PHP objects. He also talks some about the current state of the project, recent advancements and some of the things they're looking to do with it in the future (including dropping PHP 5.2 support and use late static binding).

Andrew Podner has a new post for those wanting to find out more about the Lithium framework and using models to work with your database.

Today I want to provide a tutorial on how to do some basic interaction with a database in Lithium, and I am going to rely on MySQL as a database for the purposes of this tutorial, although you have other options like MongoDB, as an example.

His example script uses the idea of "blog posts" stored in a MySQL table and code snippets are included showing how to:

• Create the model class based off of the core Lithium one
• Select all of the records from the table
• Filter down the returned values with "magic finder" methods (like "findAllByStatus")

You can find out more about the framework in the project's documentation section of their site.

Michael Nitschinger has a new post to his site today showing how you can cache the entities you've created with Doctrine using Couchbase as a simple caching tool.

As part of our ongoing efforts to make Couchbase more integrated with frameworks and libraries, we added caching support for the Doctrine ORM. [...] Caching can either be used standalone (through the API provided by doctrine/common) or integrated with the ORM functionality. We'll look at both variants through simple examples, a good documentation can also be found here. Note that at the time of writing, the CouchbaseCache is not mentioned as a caching driver because the documentation still needs to be updated.

He walks you through the steps to get everything you need installed, both through Composer and the Couchbase extension so your PHP installation will support it. He includes sample code that sets up the cache and shows how to check it to see if a key exists. With this base in place, he expands it out to working with the Doctrine ORM. He shows how to create a sample "Person" entity, inject it into the entity manager and perform a query with the Result Cache to locate the object.

On PHPMaster.com today there's a new tutorial showing you how to use the NotORM tool to work with your database:

Object Relational Mappers (ORMs) are cool. They help you to rapidly create your application without worrying about writing raw SQL queries. The idea is to simplify database interaction and avoid possible errors in writing complex queries. In fact, modern ORMs can generate Models/Entities from the database, and vise versa. But the reality of working with any ORM is that using it is only simple if you already have experience using it. To make the most out of it, you should have a deep understanding of the concepts. And there's a steep learning curve associated with any ORM.

They introduce you to the NotORM tool and guide you through some of the initial steps to help make this curve a little less steep. Their sample database contains book information (author, category, book detail, etc) with PDO making the connection (injected into the NotORM instance). They show how to do things like simple selects, filtering with "where", sort the results, doing joins and doing inserts.

In the second part of their series looking at the Laravel PHP framework and creating your first application with it. In part one you got a brief introduction to creating and configuring an application. In part two they dig a little deeper and talk about Laravel's ORM functionality.

In this Nettuts+ mini-series, we'll build a web application from scratch, while diving into a great new PHP framework that's rapidly picking up steam, called Laravel. In this lesson, we'll be working on an integral part of any web application: the Models. Along the way, we'll learn about Laravel's amazing ORM implementation: Eloquent.

The tutorial introduces you to the concept of "Models" and some of the conventions that surround them in the Laravel framework. They show some of the most common operations (CRUD) and how to define relationships between the models (has many, has one, etc). They apply this to their "Instapics" example application, creating the interfaces for the users, profiles, relationships, photos and comments. They include the code to create the controllers/views to go along with them, making a simple interface to show users and their photos.

You can find out more about the Eloquent ORM in this section of the Laravel manual.

In this recent post to his blog Jonas Hovgaard talks about how he "stopped writing awesome code" by dropping a few things from his usual development practices - like unit tests and interfaces.

If writing awesome code is using all the best practices I can find, writing interfaces, unit tests and using top notch IoC containers to control my repositories and services all over my application's different layers - Then I'm not writing awesome code at all! I've been that guy, the one writing the awesome code, but I stopped. I'm not awesome any more. Instead, I'm productive, I'm so damn productive!

He talks about how not writing unit tests (which "customers don't care about") gave him extra time to work on other code and how not using things like interfaces, ORMs and how he follows DRY, but only so far.

My personal result of doing all of this is productivity and better products. I can't tell if I did it all wrong, and that's why I'm writing better code now, but I truly believe that I'm not alone. In fact I think that most of us regular web developers, tend to do the same "mistakes" as I did.

The post has turned into flame bait and has pulled in lots of comments discussing his decisions and other sympathetic souls that feel the same way he does about some of the complexity of the "best practices" promoted in development today.

Lee Davis has a recent post that tries to combat some of the most common excuses people give for not using an ORM rather than opting to write the queries themselves. He writes in defense of the ORM and gives reasons why some of these common complaints may not matter that much.

For some reason, as of late, I can't seem to attend any user group or conference without a speaker slating ORM's. Several speakers at the PHP UK Conference this year expressed their disapproval, as well as the speaker at this months PHP London talk. However, no one is giving me a strong enough argument to not use an ORM. Remarks such as "That's a whole other talk" or "Don't get me started on ORM's" seem to be thrown about. But whenever I get a chance to talk about any concerns or issues they're having the conversation just seems to deflate. Am I missing something really terrible about ORM's that's going to creep up and bite me?

He goes through and lists some of the most common and explains how, once you get past some of the initial impressions, they might not be so bad:

• Using ORMs means having a one to one relation between object and table
• ORMs produce sub-optimal SQL and far too many queries
• Using ORMs means using active record
• ORM is slower than just using SQL, Unlike other abstraction layers, which make up for their performance hit with faster development, ORM layers add almost nothing.
• But just pulling out arrays are quicker
• Incorrect abstraction - if you don't need relational data features you're using the wrong data store

On the Liip blog there's a recent post looking at table inheritance with Doctrine, the popular PHP ORM tool. In the post, Daniel Barsotti talks about a database model that needed some updating due to their searching needs.

Our first idea, and it was not that bad, Drupal does just the same, was to have a database table with the common fields, a field containing the type of item (it's either an event or a blog post) and a data field where we serialized the corresponding PHP object. This approach was ok until we had to filter or search LabLog items based on fields that were contained in the serialized data.

To resolve the issue they turned to multiple table inheritance, relating the LabLogItem to both a BlogPost and Event. They also show how it could be modeled with a single table, but opt for the multiple method. Included in the post is the Doctrine-based code showing how to create the parent entity for the LabLogItem and the two child entities for the blog post and event. There's also a brief snippet showing how to use them with the EntityManager.

On DZone.com today Giorgio Sironi has a new post showing how you can use Doctrine with MongoDB to work with Document objects from the database.

In the PHP world, probably the Doctrine ODM for MongoDB is the most successful. This followes to the opularity of Mongo, which is a transitional product between SQL and NoSQL, still based on some relational concepts like queries. [...] The case for an ODM over a plain Mongo connection object is easy to make: you will still be able to use objects with proper encapsulation (like private fields and associations) and behavior (many methods) instead of extracting just a JSON package from your database.

He briefly mentions that the PECL extension for Mongo needs to be installed prior to trying out any of the examples. His first example shows how to create a DocumentManager (similar to the normal EntityManager for those familiar with Doctrine). He also shows an integration with the ORM and shares some of the findings he's made when it comes to versioning the resources (hint: annotations are your friend).

Jeremy Cook has put together a new post showing how he got PUPUnit, Doctrine and MySQL to "play nicely" together when he was writing up some of his tests in a current application.

One of the pain points for me though has been in getting Doctrine setup with PHPUnit for testing. One of the main Doctrine contributors, Benjamin Beberlei, has written a package called DoctrineExtensions which amongst other things adds a class called DoctrineExtensionsPHPUnitOrmTestCase which extends PHPUnit's DbUnit database test case class. This all works well in principle but hits a major snag in reality: MySQL doesn't allow InnoDb tables with foreign keys to be truncated. PHUnit's database extension truncates the database tables before each test run and inserts a fresh set of data to work with.

To work around this issue Jeremy by porting over a method posted by Mike Lively over to Doctrine as a custom "MySQLTruncate" class (code included in the post). He also includes some sample code showing it in use - a basic ORM test case that calls the truncate method when its set up.