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

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.

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.

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

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.

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

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.

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

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.