In this new post to the GotoTech.com blog Eric Burns talks about a way he's "tamed Doctrine's 2000 flushes" with a wrapper around the EntityManager to make controlling the database flushes simpler.

For my project I decided to use the Doctrine 2 ORM to manage my data layer. We also use this at work, so the biggest reason I chose this was to be able to learn more about Doctrine to help me in my job. But this decision also makes sense for my project because my entity relationships will likely be fairly straightforward for the most part and using an ORM will allow me to make a lot of progress very quickly without (I hope) causing me lots of trouble later on.

His handy wrapper (Data Manager) makes it simpler to perform the flush and still take transactions into consideration. His simple class includes "flush", "commit" and "startTransaction" methods that don't actually perform the flush until the commit is called.

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.

In a recent post Marcelo Gornstein takes a look at using dependency injection with Doctrine2 using his Ding container.

This article will show how we can develop software in php with a nifty design and architecture, and very much like other languages like java, using an ORM and an AOP, DI, Events container. I will assume you've read (or at least took a quick look) at this article that explains the tree layout used throughout the code, and that you have some basic knowledge of Doctrine2 and used it before on your own.

He starts with the result - an easy to use, self-contained (and decoupled) system for accessing the Doctrine2 instance. It's event-driven and uses Aspect-oriented programming to mange interactions between components (or as he calls them "beans"). Code is included for the entire process for a logger, the User entity, entity manager, user repository and transactional aspect. You can find the complete source for his example on his github account.

In this new post to his blog Ade Slade shows how to integrate the Pimple lightweight dependency injection container with a Zend Framework application.

This post will describe a way to integrate Zend Framework 1 and Pimple. A complete working version of the code is available on github. Thankfully, Zend Framework 2 features its own Dependency Injection Container. Happy days. Still, if you're not prepared to wait, you may find this useful.

He shows how to add a resource plugin into the Pimple container - an entity manager that's part of Doctrine. He creates his controller, pulling the manager from the Pimple container and includes a unit test for the controller too (using PHPUnit, but he also suggests Mockery).

NetTuts.com has posted a second tutorial in their series focusing on the Zend Framework today. In this latest article they focus on integrating the powerful Doctrine ORM with a Zend Framework application.

Ready to take your PHP skills to the next level? In this new "From Scratch" series, we'll focus exclusively on Zend Framework, a full-stack PHP framework created by Zend Technologies. This second tutorial on our series is entitled "Models and Integrating Doctrine ORM".

They continue on from their previous tutorial to talk about what models are (with an example involving "bankers"). They also show how to use the Zend Framework "zf" command line tool to configure your database settings, set up the tables and download/bootstrap the Doctrine code. The include the code to create some simple models and how to use them to create and update records in your database. You can grab all of the sample code for their examples from The Next Social's github repository.

On PHPBuilder.com Jason Gilmore has posted a first peek at Zend Framework 2, an upcoming reworking of the popular framework with PHP 5.3-centric features.

Version 2.0 seeks to improve upon the current release in a number of ways, focusing on making it easier to get started using the framework, improving performance, and fully embracing the latest PHP language enhancements made available to version 5.3. [...] Although the official release won't be out for several more months, it never hurts to take an early look at what the future holds for a technology used by countless PHP developers around the globe. In this article I'll present a meandering introduction to the key version 2.0 features that I find particularly compelling.

He starts with a brief tutorial on getting the latest version of ZF2 from the git repository and creating basic project. The changes in the framework have fallen into a "rewrite only where it makes sense" mentality and changes have really only been made transparently to the backend or as new features/components like module management and Doctrine 2 integration. He also points out a few resources you can use to keep up to date on the latest from the framework including the changelog, mailing list and the ZF2 blog.

On DZone.com today there's a new post from Krzysztof Kotowicz sharing a presentation of his about protecting your application from SQL injection.

The materials teach how to use prepared statements, how to escape and write secure stored procedures. Many PHP projects are covered - PDO, Propel, Doctrine, Zend Framework and MDB2. Multiple gotchas and caveats are included. I discuss why escaping is usually the wrong choice, which practices to avoid or follow and how stored procedures sometimes offer no protection at all.

The presentation (as posted to Slideshare) starts with some of the basics - what SQL injection is and an example of how it could be used to bypass security. He covers how to use prepared statements in each of the technologies (with code snippets), methods for escaping data and how to create stored procedures that are protected from the same threats.

On the Leaseweb Labs blog there's a recent post looking and some of the things you can do to optimize Zend Framework and Doctrine when used together for database access.

In principle, the combination of Zend Framework with Doctrine is not too difficult. But first let's talk about the preparations. According to the author of Zend Framework, the default file structure of project can be a bit more optimal.

They start by describing this optimized file structure (moving the models out of the modules and into the library) and what you'll need to change in Doctrine's configuration to make this work. The post also includes examples of what the larger config should look like when the changes are made. They show how to extend the default Doctrine CLI tool to make a custom "sandbox" instance and show some tuning you can do on the Zend Framework side so it can optimally work with the new models.

In a new post to his blog Jigal Sanders shares some of his experience in working with Doctrine 2.1 in a Zend Framework-based (1.11.9) application for his database interface needs.

I hadn't been using Doctrine for a while and decided to pick it up two weeks ago, as we wanted to see if we can implement it for our CMS at our office. So I setup a clean installation of the zend framework (1.11.9) and tried tried to implement Doctrine. The main goal was to see if we can reverse engineer existing databases and then start doing some queries.

There were three things he found in the process that caused a few issues:

• A confusing set of terms and features that weren't explained well enough to know their use
• Getting things like autoloaders working with the Zend Framework to make things work well together
• A potential bug with the "name" property on an object and some automatic namespacing Doctrine tries to do

There are already a lot of resources available on the Internet. I have looked at various configurations, like for example the 'bisna' project from Guilhere Blanco. But I keep saying that it's really difficult and has a steep learning curve. Doctrine 1.2 was really simple. Doctrine 2.x is a lot more difficult to get into.

On the PHP on Windows section of DZone.com today Giorgio Sironi has posted about a different sort of object mapping than is usually thought of with databases - object-document mapping.

The Data Mapper pattern is a mechanism for persistence where the application model and the data source have no dependencies between each other. [...] But everytime we talk about the Data Mapper pattern, we assume there is a relational database on the other side of the persistence boundary. We always save objects; we always map them to MySQL or Postgres tables; but it's not mandatory.

He talks about two projects, MongoDb_ODM and CouchDb_ODM, that the Doctrine project is working on to help make working with document-driven databases as simple as the usual ORMs. He includes a brief code snippet showing how the feature will work (hint: a namespace of Document instead of Entity). He lists some of the features - including the usual ORM capabilities, support for collections, cascade of persistence - and where you can get the latest code for it (from github and PEAR

On the Test.ical.ly blog there's a new post looking ahead to the next release of PHP, 5.4, and what it could mean for some of the popular tools out there - specifically Symfony and Doctrine.

It shouldn't be long until the first alpha version of PHP 5.4 will be released and with it there will be a lot of new features such as array dereferencing and traits to name but a few. What does that mean to the roadmaps of Doctrine and Symfony?

He mentions the experiments that are proposed on the Doctrine project that could be one of the major driving forces behind Doctrine 3. He points out that, as long as Symfony stays non-PHP 5.4-only, users will still have the choice of Doctrine 2 or 3. There are two issues he points out, though, that could cause problems for both projects - the choices Symfony makes in things like its quickstart guide and the DoctrinBundle vs Doctrine3Bundle situation that could come up.

On the Symfony blog there's a new post about how Symfony2 is "getting easier" thanks to some recent changes with improved error handling and simpler configuration options.

With the release of the first beta approaching fast, our main focus has switched from adding new features to polishing existing ones. [...] Recently, Ryan and I have spent our time tweaking error messages, simplifying the code and the configuration, adding more documentation, and making things more consistent throughout the framework. The goal is to ease the learning curve and make things that people will need on a day to day basis simpler.

The changes they've made include three updates - better Twig error messaging, better configuration error messaging and some helpful changes to the Doctrine configuration to allow for auto-mapping of connections when the traditional one-database setup is used.

New on the ZendCasts.com site there's a screencast showing you how to unit test Doctrine 2 entities.

His example came from a webinar recently presented by Zend to integrate unit testing with the help of the Symfony console. He shows how to set up a configuration (sans yaml) in your Zend Framework application's setup and a bootstrap to get them all working together.

This screencast is about 45 minutes long and, if you'd like more information on unit testing with the Zend Framework, check out the side bar for looks at testing with Zend_Form and action helpers.

Chris Hartjes, after finally figuring out an issue with database migrations with Doctrine on a Zend Framework application, has posted about the process to his blog today. As he notes:

This posting is a lesson on the value of actually looking at the source code of a third-party library when you are trying to figure something out...

His problem wasn't with the features of Doctrine and how easy it made to automate things in his environments (continuous integration). His issue was that Doctrine wanted to run all of the migrations every time it was executed. Upon closer inspection, he found the key - a migration_version table in his database that held current migration information. He includes a simple Zend Framework-based script he's now using get the latest value from that table and execute only the migrations after that. The migrations are executed in order - he recommends using a timestamp or formatted date on the filename to set the order.

On the Ibuildings techPortal today Harrie Verveer has a new post looking at database version control - one of the more difficult topics for development groups - and some of the technology that can be used to help make it a bit simpler.

Database version control is something that most developers have to deal with regularly, yet only a few have actually thought about what solution might be best for them. Most people have a solution that sort of works for them, but when you ask them about the subject they are pretty convinced that there must be some better way to manage database changes, they're just not entirely sure what that solution is - but the silver bullet must be out there somewhere, right?

He starts where most developers start - their own custom script. It usually will take in a series of patch files and apply them one by one. In this case a "patch level" is stored somewhere (file/database) and is checked when the deployment is done. He points out a few issues with this method including patch naming issues and branching. Taking a step up the technology tree, he looks at other solutions like Phing+DBDeploy, Liquibase, and Doctrine migrations to try to help you find your project's "silver bullet".

Flyn San has a new post to his blog today about a better Doctrine 2 module he's created for use with Kohana framework-based applications.

Since releasing my original Doctrine 2 module for Kohana 3 (found here), I've done a bit of reshuffling of folders and added some additional features from my old Doctrine 1.2 module. Due to the extent of modifications, I decided to put up a new post with some added information on how to use the new module. For the impatient ones out there, here's the download link: Doctrine 2 Module for Kohana 3

He spends the rest of the post explaining the structure of the module, how to get it installed and working and some sample schema files (for Product and Serial tables in yaml) you can import and test with.

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.

Jani Hartikainen has posted his technique for making the Doctrine version 1 style "soft delete" in your Doctrine 2 powered application.

Doctrine 1 has the concept of behaviors which you could add to your models. One of these was the soft-delete behavior, which allowed you to "delete" records without really deleting them. Doctrine 2 does not have behaviors due to various reasons. However, I needed a way to have a model which worked like soft-delete. Let's see one approach to creating such behavior in Doctrine 2.

He introduces the idea of a "soft delete" - essentially a flag that gets set to let the rest of the application think that row is essentially deleted. He shows you how to create the similar functionality via a repository that filters the data for you. He includes code to help you along, defining the find/findOneBy/findBy and the example repository that lets you set an "is deleted" property on the object.

On DZone.com today there's a new article from Giorgio Sironi about making the switch from Doctrine 1 to Doctrine 2 and some of what might be involved.

Doctrine 2 is an implementation of the Data Mapper pattern, and does not force your model classes to extend an Active Record, nor to contain details about the relational model like foreign keys. [...] Note that you will have to run your application of PHP 5.3 for Doctrine 2 to work, mainly because of the use of namespaces in it.

He talks about some of the other differences including maintaining PHP classes and the metadata in them rather than just a YAML schema to map to your database. There's also a difference in how to interact directly with the Doctrine engine. Direct access has been replaced with a dependency injection approach.

New on the ServerGrove blog today is a quick post talking about how you can enforce key constraints on a MongoDb with Doctrine in Symfony.

Of course you can define unique indexes to prevent duplicate values and there are a couple of different syntax options to do so, which are clearly defined in the official documentation. But defining and creating the indexes is not enough. You must specify when you want to enforce the constrain, this is due to the fact that the PHP driver needs to tell MongoDB to throw an error when a duplicate key is found.

The fix is as simple as adding a "safe" option to the "flush()" call on your database object. If you give it a value of "true", the ORM is smart enough to handle things on its own.

On the ServerGrove blog there's a new post showing you how to create indexes for your Doctrine ODM documents in a Symfony 2 application.

Creating indexes in NoSQL / Document-based databases is quite different compared to traditional relational databases. Since the former are schema-less (there is no table creation), indexes do not get created when the collection or the document is created or inserted. Here is a quick tip that will create all the indexes defined in your documents when using Symfony 2 and Doctrine ODM for MongoDB. Indexes are a great way to speed up your queries, in fact, it is a crime not to include them in your documents.

Adding the index is as easy as putting a new annotation on the property in its document class (for @Index) and run a bit of code in Symfony to build it out. The two lines you'll need to execute are included in the post.

Nurul Ferdous has posted his "two cents" on Doctrine - his thoughts on the good and bad things about the popular ORM tool.

What is Doctrine? Doctrine is a popular ORM for PHP which works with RDBMS via PHP objects. This is built inspired by Hibernate from JAVA. This acts as an abstraction layer between PHP and RDBMS.

In his list of good things about Doctrine are things like its hiding of business logic, automatic CRUD, automatic modification of DQL queries, migrations and unit testing interfaces. On his "bad list" are things like not being able to use foreign keys as an identifier, heavy emphasis on an "id" column, not all data types are in DBAL and the SQL constructs missing in DQL. He also includes a scenario where he definitely not use Doctrine - a specific example from a project he just worked on that pushed the limits of the tool.

Daniel Cousineau has a new post to his blog today looking at an alternative that can be used for pagination in your MSSQL queries than the trick with TOP and reversing the ORDER BY in Doctrine.

As ugly as this technique is, it works. The problem is it requires an extreme amount of intelligence or an extreme amount of simplicity in the query in order for an automated system like Doctrine to be usable. The biggest caveat with this technique is good goddamned luck paging your query if it doesn't have an ORDER BY. And sometimes queries that are complex enough break the modified Zend_Db code. There exists an easier MSSQL paging technique. Using features first available in SQL Server 2005, with only 1 subquery you can mimic MySQL's LIMIT clause with ease.

He includes the query that will make it happen (the SQL for it) and then the implementation as an adapter you can use to get it to cooperate in your Doctrine queries.

In this new post to his blog Gonzalo Ayuso looks at building an ORM (don't worry, he recommends something like Doctrine first) as an exercise to understand how they're constructed and how one could fit his goals.

What's the motivation for me to build this ORM? The answer is a bit ambiguous. I like SQL. It allows us to speak with the database in a very easy way. [...] So the idea I figured out was to create a set of classes based on my tables, in a similar way than traditional ORMs to help me to autocomplete the fields and table names.

He creates a simple example with a "test" table with three columns with a mapped class (in the "Orm" namespace) that will allow IDEs to follow down the path to fetch the data from the "id", "field1" and "field3" columns. The complete code listing for his example is at the end of the post - PHP 5.3 friendly, of course. Some trigger and scaffolding examples are also included.

On his blog today Jonathan Wage has posted a tip on getting MongoDB connections and queries to work through the Doctrine ORM layer:

Since the start of the Doctrine MongoDB Object Document Mapper project people have asked how it can be integrated with the ORM. This blog post demonstrates how you can integrate the two transparently, maintaining a clean domain model. This example will have a Product that is stored in MongoDB and the Order stored in a MySQL database.

His code shows how to define the document and entity for the connection (a Product and Order) and creating an event subscriber to lazy load the product. He creates a sample Product and an Order for it and save them to the database. He also includes code to pull an order back out by its ID number and get an Order object back out (with Product data inside).

New on Developer.com today there's a new article looking at one of the more powerful ORM tools available for PHP - Doctrine.

Because of the relational database's pivotal role in driving Web applications, a great deal of time and effort has been put into creating tools that not only simplify the task of mapping database tables to a programming language's object-oriented class structure, but also facilitate the management of your data and schemas over the project lifecycle. [...] The PHP community also has a powerful database integration tool at their disposal: a project known as Doctrine.

They help you get started with this powerful tool by showing you how to get it installed, create a sample schema and loading some fixtures (base data). There's also a quick snippet of code showing you how to grab information from a sample user table and display the name of the user.

Michael Kimsal has put together a Zend Framework starter kit currently posted over on github here.

Feel free to fork it and send me pull requests. There's a load of things I'd like to do to/with it, including a default basic authentication and user mgt system, a basic forms generator, some menu stuff on the side, and some other small stuff. It's got Doctrine built-in, and ready to go with a sample book/author object set, although no sample *data* yet, nor any examples of how to use the code specifically. Maybe I'll add some of that soon.

The ZFKit brings helps you get started quickly by giving you an example of a site that combines Doctrine, PHPUnit and the Zend Framework into one "ready to go" bundle.

In a recent post to his blog Court Ewing talks about what he sees as one of the most important parts of any framework-based application - good, easy models that are simple to use and well structured.

By treating your models as nothing more than a place to dump your data, you are doing yourself and your application a severe disservice; your business logic is going to be scattered throughout the rest of your application, and you will have a progressively more difficult time as you try to maintain and build upon your existing system. Do not fall into the anemic model trap.

He gives examples of good models (based on how Doctrine 2 handles them) to work with the data for a sample blogging application. His main "Article" model pulls from an abstract one to help define some relationships and magic methods to handle class properties in a protected and private way, depending on the context. He finishes the post with an example of how to use these new model classes to interact with his blog data.

In a recent post to his blog Anna Filina looks at internationalization in Doctrine and how Symfony auto-builds things to take care of it for you.

If you use Doctrine, then you probably know how lazy loading can hurt your performance. I carefully craft every query to everything that I need in one shot, but only what I need. One thing that evaded me at first was the i18n part. I am pleased with the way Doctrine + symfony magically creates all my models and database tables with i18n support.

She talks a bit about the internationalization (i18n) support is put into the schema.yml file and the bit of confusion she had over how to handle a left join using its structure. The key lies in the Translation relationships.

Michael Kimsal has a new post today looking at using Doctrine models in a Zend Framework application and how to get them to autoload when you need them with the help of Zend's Zend_Loader_Autoloader.

I would have expected there to be some explicit reference to how to set this up, but the best I can find are general examples where the Doctrine models directories are appended to the include_path in a ZF index file. Shouldn't there be a way to explicitly have the Doctrine subsystem react to requests for models as well?

He works through the process he followed, including the possibilities of extending the Doctrine Core and accessing the $_modelsDirectory property, but didn't have much luck because of how Doctrine forces the autoloading. He asks for help and gets some good suggestions in the comments on where to look fro documentation and a possibility of skipping the Doctrine loader all together.

The ZendCasts.com site has recently posted a quick video covering logging and Doctrine event listeners in a Zend Framework application.

This short video is going to be the last in my 2009-2010 series on Doctrine 1.2. I'm wrapping it up with a little example of adding timestamps, logging and using Doctrine's event listener architecture.

The tutorial shows you how to pull in the features of Doctrine to make it easier to create a more complex logging system. He shows how to set up the schema file, add in controller functionality and backend models to make things all work together happily. You can get a copy of the project he's building from his subversion repository.

Doctrine allows you to set up relationships to link data in various tables together. Unfortunately, those aren't always in the order they need to be in. In a new post to his blog Chris Hartjes shows you how to sort these relationship results just by adding a simple line to your request.

I started digging around via search engine. Took me about an hour to find the solution. First, it took me half the time to dive deep enough to find out WHERE I can define the default sort order. Surprisingly, it was in an area that made total sense but I could not find before.

You can see an example of it in the "hasMany" call in his code snippet - the addition of the "orderBy" option and the value showing the sorting order. Here's the StackOverflow page that gave him the answer he needed.

The next ZendCast in the user authentication with the Zend Framework's Zend_Auth has been posted to the ZendCasts.com site today. In this new screencast, they look at how to integrate it with Doctrine to automatically validate users against the information in your databases (following up on this first part of the series).

Here's the second part of my Doctrine / Zend_Auth example. In 15 minutes, we create a logout, login and protected area that's reliant on the ZC_Auth_Adapter adapter we created in last week's video. Notice how there's no code in the IndexController exposing the authentication implementation,

You can grab the code to follow along or build it as he goes. You'll need a copy of Doctrine up and working to keep up, though.

New from the ZendCasts.com site today there's this new screencast looking at the integration of the Zend_Auth_Adapter component of the Zend Framework and the Doctrine ORM library to split out the authentication from the persistence layer.

I've been using Doctrine a lot in my own work, and recently found myself itching to have tighter integration between Zend and Doctrine when it comes to user logins. Luckily, Zend provides a very simple interface with regards to Zend_Auth. This way, it's easy to decouple your persistence layer (in my case Doctrine) from the authentication layer.

He also recommends checking out Palo Verede's look at the same topic. You can watch the screencast here and grab the code for it here.

In a new post on the Rdavid.net blog there's some discussion about Zend Framework models, the best approach and a "Service Class" idea.

After some more thought and lots of research on the subject, I've come to a solid point where I actually have something to try out which seems semantic aside from the naming of the class (Service Class) '" but this is derived from what some people are talking about in ZF circles starting from Matthew Weier O'Phinney who was coining it as the "Gateway to the Domain" from early on, then later changing it to "Service Class".

He defines what his service class idea is - a layer between the database and each of the models that allows them to be agnostic about what kind of service they're using. He also breaks down some of the key points around his approach including the fact that the Model Service can create Forms and that the Model Service can use the Zend_Cache component directly for improving performance. Be sure to check out the comments for thought from other Zend Framework developers.

On Rdavid.net there's a post with the results from some tests run on hos much memory the Zend Framework and Doctrine used both with and without the APC caching.

I have decided to run with Doctrine as my Domain Model in Zend Framework projects. The thing is, if I'm going to commit to this, I need to know that applications I build in the future with the Zend Framework while using Doctrine as an integral part of the Model layer will not take performance hits from things like memory usage. With Doctrine doing a _lot_ of magic, I thought that this would be something that I wanted to see for myself. 4MB Memory to execute a simple Query?!?! Ffffff#$#!!!!

He includes the code for his testing procedure - creating a basic Doctrine object and running a "fetchOne" query and measuring the memory consumption with the memory_get_usage function. His results with the APC caching came out faster by about 60-70 percent.

New on the ZendCasts.com site is this recent screencast about the best approach for integration of the popular Doctrine ORM and the Zend Framework.

his video is my humble approach of combining some of the learning brought about over the last few weeks on Zendcasts, as well as suggestions from Doctrine developers. The goal of this video is to show how you leverage the existing resource loading tools in Zend to have a model structure that reflects Zend's best practices.

The code is provided if you'd like to follow along with this (about) twenty-five minute presentation.

The Zend Developer Zone has posted the second part of their look at pagination with the combination of the Zend Framework, Doctrine and PEAR and how the Zend_Paginator component compares to the PEAR and Doctrine alternatives.

In the previous segment of this article, I introduced you to the Zend_Paginator class, which provides a flexible API for paginating any data collection, whether it is expressed as an array or a database result set. [...] This article will explore two such alternatives, the PEAR Pager class and the Doctrine Pager class, and give you a crash course in how you can use them to quickly add paging and sorting features to your PHP application.

The article gives examples for both of the other methods - a simple pagination of database information with the PEAR pager component (and other packages that can make the results more effective) and the creation of a Doctrine instance where the results are handled via a series of built-in method calls.

New from the ZendCasts.com site there's a new screencast looking at the relations you can create between Doctrine and your Zend Framework applications.

This short podcast covers how you can easily build a form using Zend's MVC model via Zend_Controller and using Doctrine for persistence. You can download the source code or browse it online. Enjoy!

This screencast is part of a series they've been doing on Doctrine including Doctrine Relations and Data Fixtures and Writing Doctrine Unit Tests with Zend_Test.

On the Zend Developer Zone there's a new tutorial on how to use the combination of Doctrine and more PHP to connect with Flash Builder to create a simple classified ad system.

This article shows how to set up Doctrine and use it in PHP code. Then, it exposes PHP services to Adobe Flash Platform applications using Zend_Amf. You'll then call the Doctrine-enabled services from a Flex client. Finally, I'll show you how to switch your database from MySQL to SQLite with four lines of code. And I won't write a single SQL statement.

He shows how to set up a full Apache/MySQL/PHP installation with Doctrine, Flash Builder Alpha and the latest edition of the Zend Framework. He shows how to set up the models, connect Flash Builder to the app via the Zend_Amf component and how to build the frontend for the app inside Flash Builder.

On the Zend Developer Zone there's the first part of a series looking at pagination and sorting of data with the combination of the Zend Framework, Doctrine and PEAR.

When building database-backed applications, one of the important problems for a developer or user interface engineer involves making large data sets more manageable by, and therefore more useful to, application users. [...] Back in the good old days, adding pagination to a PHP application was mostly a manual task, involving offset calculations and custom query generation. In recent years, the task has become significantly simpler, mostly due to the presence of ready-made pagination components in most common frameworks.

His tutorial uses the Zend Framework, Doctrine and the Pager, MDB2 and Structures_Datagrid PEAR packages. He starts with a basic select and format kind of example to show a few lines per page. To improve it (for larger data sets) he shows how to use the Zend_Paginator to only grab the rows needed for the page. Finally, he adds in code to allow for column sorting, making it easy to reorganize the results how you'd like.

Since the Symfony framework project has such tight integration with both the Propel and Doctrine ORM layers, they thought they'd share some statistics on the usage of both as mapped through the stats from their Jobeet tutorial.

As for any Open-Source community, it's not easy to find metrics that tell you what people use and how they use it. You can measure the number of tickets for a specific feature, count the number of people asking for help on Propel or Doctrine. But for the Propel vs Doctrine question, we have two more reliable metrics.

As is shown in this graph of the total Jobeet traffic in 2009, Doctrine is winning by a long shot. That's not to say that you can't still use Propel is that's what you and your application are using, this is just showing the overall popularity of each of the ORMs.

Juozas Kaziukenas has posted the third part of his series looking at the powerful combination of Zend Framework and the Doctrine ORM layer.

During last two months I spent massive amount of time tweaking Doctrine ORM framework and making it to perform as fast as possible (as you might have noticed from my never ending tweets). This post is devoted to performance and efficiency, with practical tips & tricks how to reduce memory usage, make it work faster and save resources.

He's broken it up into two main parts with points underneath:

• Speed including a look at hydrators, DQL and optimization
• Memory usage and how you can optimize things that seem simple and some recommendations of tools you can use to resolve some of the trouble spots.

Adam Jensen has written up a quick tutorial about using Doctrine record listeners to link a Zend_Acl component with your database.

In previous Zend Framework apps I've written, I often handled access control at the level of the controller action. Each action was represented in the ACL as a resource, and the ACL logic was applied by a custom plugin just prior to any action dispatch. [...] As a result of these concerns, I decided on a lower-level, model-centric approach for this blog: my models are my resources. Each model class implements Zend_Acl_Resource_Interface, and the ACL specifies "create," "read," "update" and "destroy" privileges for each class (more or less).

Checking for the permissions with a setup like this can be time consuming, though, so he found an ally in the record listeners Doctrine allows you to set. He combines a Doctrine_Record_Listener object with a Zend_Acl one in a preInsert method with a getCurrentRole to add the user handling all in one place.

Juozas Kaziukenas has posted the second part of his series looking at the combination of the Zend Framework and Doctrine (part one is here). In the previous part he explained the technologies some. In this second part of the series he focuses more in getting Doctrine set up and working.

Today we start actual development with Doctrine and Zend Framework. Base of this post is my code which I have been using for quite a few projects and it worked really well.

He walks you through the steps to getting Doctrine set up - creating the database, downloading and unpacking the latest version of Doctrine, setting up your application.ini file and creating the models from the database. Add in a sample query and things should be working perfectly.

Juozas Kaziukenas has started a new series of posts to his blog today with this first part of his look at combining the Doctrine ORM with Zend Framework applications.

It was quite common to use Zend_Db_Table as base models class, but it was simply not practical. When you start dealing with relations and hierarchical data types it starts to get really tricky, because simply Zend_Db_Table doesn't provide an extensive enough functionality. So half a year ago Zend Framework developers started to look for better solutions.

An alternative (and a very powerful one at that) was found in Doctrine - an object relational mapper tool that sits on a database layer. Doctrine 2 will even be the first ORM with seamless integration between the Zend Framework (and Symfony). He briefly touches on what some sample code might look like and the command to build out your model classes from predefined YAML files.

Daniel Cousineau has posted a quick guide to migrating database information with Doctrine:

I was talking with someone [...] here at ZendCon and discovered that they were having trouble with migrations in Doctrine. Having gone through the same issues of Doctrine seemingly not being able to figure out your changes and generate migration classes, I thought I'd post the solution here for future reference.

It's four quick steps that'll get Doctrine to automatically generate the differences (deltas) and upgrade your models to reflect these changes.

On the Symfony blog there's a recent post showing how to integrate the framework with Doctrine 2 via the sfDoctrinePlugin:

Today I am happy to tell you that this version of sfDoctrinePlugin is now available and ready for you to use. This article will give you a little information about how you can get started using it today!

Installing and enabling the plugin is as easy as a svn checkout and changing a few settings in your project's configuration files. You can then define your database connection and schema information settings so that the rebuild ("symfony doctrine:build") will build out correctly. They include a simple example, a repository class, to let you be sure everything is up and working correctly. You can find more information about Doctrine 2 from its online manual.

Following some issues with the Phing and Propel subversion repositories for Symfony, Fabien Potencier has made a few changes to aid in their future stability.

The Phing and Propel Subversion repositories have suffered from long downtime periods quite often recently (last one was today). It is quite annoying as when it happens, you cannot easily update your symfony repositories, let alone the checkout of a symfony branch. To make things worse, the Doctrine repository also had some problems recently. A lot of symfony users are quite upset by the situation, myself being the first one.

The solution - create some mirrors to provide more than one source to fetch the latest checkouts from. Here's the list of the new resources: Phing mirror, Propel mirror, Doctrine mirror.

Matthew Weier O'Phinney has a new post on something he's been asked about a lot - autoloading Doctrine into a Zend Framework application.

A number of people on the mailing list and twitter recently have asked how to autoload Doctrine using Zend Framework's autoloader, as well as how to autoload Doctrine models you've created. Having done a few projects using Doctrine recently, I can actually give an answer.

His short answer - "attach it to the Zend_Loader_Autoloader". For those needing the long answer, he goes through a simple example of creating the loader object, registering a new namespace and pushing in the Doctrine functionality as an autoloader. The bootstrap class can then be modified with an "_initDoctrine" method to pull in just what scripts your app might need.

As is mentioned in this new post to Giorgio Sironi's blog, the latest version of Doctrine now includes lazy loading functionality.

Lazy loading is the capability of performing a expensive operation on demand, only when it reveals necessary from a client request. [...] In Doctrine 2 I made some architectural choices implementing the proxy approach, which substitute a subclassing object to every association which is not eager-loaded.

There's two main places you can see these differences - in the one/many to one associations dynamic proxies and collection interface.

The second part of the IBM developerWorks series looking at the Agavi PHP framework has been posted. In it Vikram Vaswani loks at adding forms and database support to his example via Doctrine.

While Agavi can certainly be used to serve up static content, it really shines when you use it for something more complex. And in this second part, you'll do just that - over the next few pages, you'll learn how to receive, validate, and process input from Web forms, as well as connect your Agavi application to a MySQL database.

He returns to his simple templated example site and shows how to use the command line agavi tool to create the routing and controller to handle the "contact us" requests. He includes form validation examples, how to use the population filter, and how to generate the Doctrine models to connect with the form directly.

Feel like getting involved with a PHP-based Open Source project, but don't know where to start you might consider getting involved with the Doctrine project - they're currently looking for a few good programmers.

Many of you probably know Jonathan, Guilherme and Roman as being the core developers of the Doctrine project over the past 2 years. While this constancy is a good thing it's also problematic. [...] So we are left wondering. What can we do differently to get more people involved? Given the amount of users and noise about Doctrine around the PHP scene, we find the absence of new contributors quite strange

The Doctrine project is looking for developers (on both the 1.x and 2.x release series) to either get involved of to help them out with suggestions on how to get others interested in working with the project. To get in contact with the team, you can just send an email to any one of the three: jonwage [at] gmail [dot] com (Jonathan), r.borschel [at] gmx [dot] net (Roman) or guilhermeblanco [at] gmail [dot] com (Guilherme).

Jani Hartikainen takes a look at two of the major PHP ORM libraries in this new post - Propel and Doctrine.

The best PHP ORM libraries, Doctrine and Propel. Last year I compared them to each other, and now it's time to get a fresh look at how they have advanced in about a year - Is Doctrine still the better of the two? This time, I'll also look at the features of each in more depth.

He goes through some of the features (basic and advanced), how easy they are to use and their connections to the database. His personal preference? Doctrine works better for his needs.

Guilherme Blanco passed along a note about the latest releases from the Doctrine project, Doctrine 1.0.8 and 1.1.0-RC2:

Today I am happy to tell you that we have two new versions of Doctrine available for you to use. The first is the monthly maintenance release for Doctrine 1.0 and the second is another release candidate for the newest major version of Doctrine, 1.1. As always you can grab them from the downloads page.

Updates in these two versions include a few backported fixes from 1.1, updates to the Doctrine_Query::count() method for optimization, and several fixes in the Release Candidate in preparation for the next release. You can see the full Changelogs here: 1.0.8 and 1.1.0-RC2.

In a quick post Jani Hartikainen take a look at some optimization tricks you can do to help get the most out of your Zend Framework/Doctrine application.

I decided to try profiling my quiz application to see if I could speed it up. Not surprisingly, biggest performance penalties came from loading classes and Doctrine's ORM magic. [...] As you may have heard, optimizing without profiling first is a bad idea, as you may think something is slow when something completely different would be better to optimize.

some of his suggestions include:

• Removing all require_once calls from the Zend Framework library
• Change the include_once_override setting if you're using APC
• Using the query cache in Doctrine
• Using the Doctrine_Table find functions rather than the Doctrine_Query objects

The symfony blog has posted an update on the status of their "Practical symfony" book - the Doctrine version has officially been released!

Last week, we released the "Practical symfony" paper book (380 pages). The "Practical symfony" book is based on the Jobeet tutorial, and is the best book to read to get you started on symfony 1.2. It describes everything you need to know to develop professional web applications with the symfony framework.

As for the Propel edition, we have worked hard to update the Doctrine edition as fast as possible. The Doctrine version is now up to date and thanks to Jon work, you can even enjoy a tagged repository for each day of the tutorial.

The book works through the Jobeet tutorial series they posted at the end of 2008 to create a complete job posting website with the symfony framework.

On the Symfony blog today there's a new post from Fabien Potencier about a new book that's just been released and might be of interest to those wanting to get into the framework - Practical Symfony.

Two years after the publishing of "The Definitive Guide to symfony" book, I am happy to announce that the Jobeet tutorial is now available as a printed book: "Practical symfony". During the last two weeks, I have updated and enhanced the Jobeet tutorial based on the feedback from the community. I have also updated the screenshots to reflect the new Jobeet design. The "Practical symfony" book is the printed version of this tutorial and as such covers the symfony 1.2 version.

The Jobeet tutorial was their 2008 "advent" piece that created a job posting website from scratch with each day focusing on a different aspect of the application. There are two versions of the book (Propel and Doctrine) but for now, only the Propel version can be purchased over on lulu.com.

In this new post to his blog Jani Hartikainen looks at implementing the Data Access Object pattern in your PHP applications.

The advantage of this is that you can easily implement different methods to persist objects without having to rewrite parts of your code. I'm again going to use the programming language quiz game I wrote as an example. Since I initially wrote it to use Doctrine ORM directly, and both the old and new code are available, you can easily see how the code was improved.

He starts off with a look at the pattern itself (including a diagram of how an example would work with Doctrine) followed by the creation of the models for his Questions example. Add in the factory to create an instance and an exmaple of it in action and you're there.

The symfony blog has a new post spotlighting one of the new features of their 1.2 release - updates to its Doctrine functionality.

A lot of awesome stuff has been added recently to the next major symfony release, 1.2. Fabien has worked very hard to add without a doubt the most sophisticated features of any PHP framework that exists today. Not only are they nice features but he has implemented them in a OO way so that it is easy for me to implement the same features with another ORM, Doctrine. All this is done with very little work by me. So, give a big thanks to him if you enjoy this.

Included in the post is a real-world example showing how to use the symfony command line to build out an environment and create connections to the articles, categories and authors tables.

The ProDevTips site continues their look at using Doctrine in PHP with this latest article in the series that adds in a simple, automatic CRUD system to the application.

I just found myself wishing for automatic CRUD, for quick and simple administrative tasks, as it turned out a very easy thing to add.

They create a model for their Company table and a new controller to handle the admin requests. Throw in some fetching functions, a bit of form handling and a bit of Smarty login and you have a simple admin form that automatically creates itself based on the columns in the table.

Jani Hartikainen talks about some updates he's made to the ModelForm class for the Zend Framework and how its been reworked a bit to take advantage of Zend_Db_Table.

I've been reworking the ModelForm class for ZF a bit. Earlier this year, I discussed porting it to use Zend_Db_Table with Matthew Weier O'Phinney, for using it with Zend Framework. I initially had done some checking on Zend_Db_Table, and some small code changes to modify the class to use it instead of Doctrine, but I ran into some issues. Now, I've had some time to think about it, I've reworked the class slightly and added basic Zend_Db_Table support, too...

He talks about the two sides - the issues that came up (including relation support and differences between Zend_Db_Table and Doctrine) and how they were overcome (creating an adapter setup to accommodate for the relations issues).

As announced on the symfony blog today, Doctrine now has "citizenship" in the framework with the release of the sfDoctrinePlugin:

Today, Doctrine gained its citizenship in symfony 1.2. The sfDoctrinePlugin was linked via externals and is now officially bundled with symfony. If you've been around for a while, you'll know that this was highly anticipated and is a long time coming. To celebrate, I'll give a short little tutorial on how you can get started using Doctrine in symfony. Read below if you're interested.

The post gives you a brief introduction to how to load and use the Doctrine plugin, including how to build out an application automatically via the symfony binary.

The ProDevTips blog continues their series on using Doctrine in a sample application in this new part, a look at paginating the results from your database query.

Things are starting to become more and more feature complete. Let's look at how to implement general search and pagination.

They define the search to perform ($searchConf) and the pagination parameters ($pageConf) and apply them to their current Doctrine setup applying a simple layout to make the numbered links for switching between pages. They also define the search() method that pulls the results from the table to push into the pagination component.

On his CodeUtopia blog Jani Hartikainen gives an inside look at a feature of Doctrine, nested sets.

The Doctrine library comes with a feature called nested set, which makes saving trees in a database easy. However, it's quite easy to accidentally cause a lot of extra unneeded queries if not being careful. Here are some pointers to keep in mind while working with the nested set, and some example queries to make understanding it easier.

He gives an example, showing how to get rows from the database - parent and child - and some optimization tips to keep things light. There's also some pros and cons included for doing it either way (the standard fetching or using the more optimized versions).

The ProDevTips blog has posted the fifth part of their look at using Doctrine with PHP. This time they focus on file uploads.

It's time to take a look at how file uploads can be integrated into the Doctrine validation and CRUD process. We will have a product in the form of a digital download as an example, it will have a screenshot image that can be maximum 250 pixels wide and high. The download itself will be a zipped file.

They set up their table definitions first and set up a few validation functions (update, insert and for the file data) to work on top of that. Custom upload/uploadImage and save methods handle the user's submission while a simple delete method makes removing images easy.

In a fourth part of their series looking at using Doctrine in PHP, the ProDevTips blog moves on to implementing it in a typical CRUD interface.

They create the links between the tables (two hasOne relationships), a search() method to find the destinations for a user, a sorting method to multisort based on the subkeys of the value passed in and the methods for updating the information already in the database.

That's it for now, feel free to download this tiny Smarty and Doctrine framework. Note that for this to work you have to put Smarty and Doctrine in the lib folder. There is a login interface involved, just click submit there without entering anything. There is also an SQL file in the trip_selector folder if you want to try this out with some test data (same as in the picture above).

In this new post to the symfony blog, there's an update on the framework's latest version, Propel integration and the addition of the sfDoctrinePlugin.

After more that two years of development, the Propel team has released Propel 1.3 yesterday. This is a great achievement as Propel 1.3 sports a lot a new exciting features.

These features include PDO integration, object instance pooling, improvements to the date handling features and the addition of more default values for database schemas. There's also the updates with Doctrine:

As announced in the symfony 1.2 roadmap, Doctrine 1.0 will be officially supported and the sfDoctrinePlugin will be bundled with symfony 1.2. Doctrine 1.0 beta1 has been released two weeks ago and the Doctrine team will release Doctrine 1.0 final on September 1st.

In this new post to his blog Stefan Koopmanschap looks at a plugin for the symfony framework that has him impressed.

Using this plugin, it is not necessary anymore to really care about which ORM you pick for your project. It's the thought behind symfony 1.1 taken into the symfony ORM-selection.

He points to the DbFinderPlugin as an alternative to rewriting up the ORM code for your application by hand (or in something like Propel or Doctrine). It makes switching between ORM layers simple - just a configuration change to point to the new system.

In the third part of the series dealing with using Doctrine in your PHP applications, ProDevTips has this third part looking at a method for extending the tool's current functionality.

I simply knew we would need the extension capability that the Mdl class allows for sooner or later, I didn't expect it to be this soon though. The main problem here is saving a many to many relationship straight to the database from the $_POST array, to do that we can extend Doctrine Record with a new function I have named fromArrayExt which adds something extra to the normal fromArray method.

He shows how to extend the classes to create custom handlers for a grouping of checkboxes. The new code automatically handles their submitted values and pushes them directly into the database (with a simple save() call).

Henrik has posted the second part of his look at using Doctrine, this time in combining it with Smarty. (Check out part one here).

We are creating an MVC setup where M is Doctrine, V is Smarty and C is our own stuff we do here. The Zend Framework has been reduced to just another component library for me now, I will pick goodies when I need them.

He shows how to be "empowered, not stifled" by the framework and to combine the two technologies in a flexible, lightweight platform. His example is a simple signup form that, on submit, saves the information to the database via the Doctrine layer.

Henrik waves goodbye to the Zend_Db component of the Zend Framework in this new post to the ProDevTips blog - his new favorite is Doctrine.

It was long overdue but finally I've taken a look at Doctrine. And I'm blown away, bye bye Zend DB. [...] It's time to try and convey how awesome I think Doctrine is.

His example sets up a table definition and defines the associations between the columns for a "members" table. He defines a "city" table too and shows how Doctrine can easily combine the two and make selecting from and inserting into the tables simple.

Francois Zeninotto has posted a comparison of three different ORM (Object Relational Mapping) layers for PHP - Propel, Doctrine and sfPropelFinder (the last being a plugin of the symfony framework).

When it comes to ORMs, it's all a matter of preference. Is it, really? This post compares side-by-side the code required to perform some simple operations with three OO database requesting API. The purpose is to demonstrate that productivity, and not only style, can vary a lot depending on the ORM you choose.

He's worked up a long list of examples including methods to:

• Retrieving an article by its primary key
• Retrieving the latest 5 articles
• Retrieving articles based on a complex AND/OR clause
• Retrieving articles authored by people of a certain group
• Retrieving an article and its category by the article primary key
• Retrieving articles and hydrating their author object and the author group

Each one comes with their own (usually simple) code. His conclusions point out different "bests" of each - like sfPropelFinder being the "most magic" and that some of the limits of Propel are very frustrating.

The Zend Developer Zone has linked to a tutorial from Ruben Vermeersch about how to get the Zend Framework and the Doctrine ORM library working together.

This article will guide you through the steps needed to set up a project using both the Zend Framework and Doctrine. In a step-by-step way, we will set up a simple message board application.

He includes introductory things like the folder structure and an example of having Doctrine installed inside of it. Its all code from there on out - the bootstrap file, setting up a global handler, and how to integrate it all into their simple ZF application.

Lukas Smith got a chance to catch up with Rasmus Lerdorf (and others in #php.pecl) and "talk shop" about topics including handling large libraries and maxclients settings.

In this first post I will provide a link and some commentary on Rasmus's points regarding Doctrine (note I left independent chatter in the log in order to not have any chance of me filtering the content, but there is very little of that so I hope the discussion is still easy enough to follow).

On the Zend Developer Zone, jonwage has posted about an ORM (Object-Relational mapping) he came across that can help abstract out your interface with your backend database - Doctrine.

One of its key features is the ability to optionally write database queries in an OO (object oriented) SQL-dialect called DQL inspired by Hibernates HQL. This provides developers with a powerful alternative to SQL that maintains a maximum of flexibility without requiring needless code duplication.

The project's page gives the full details on the features it offers and has links to the latest downloads so you can try it out for yourself. There's even a blog you can subscribe to to keep up to date.

From the Spindrop blog, there's a quick new post that shares the code needed to save a file to a database inside of a symfony application:

I like to save content uploaded by website visitors to a database versus the file system. It makes it easy having the data all in one spot. I tend to overcomplicate this process, so I wanted to write down the important steps.

His two step process involves modifying your application's form helper and the code to pull the binary data out of the submit and push it into a new object.

Dave Dash has posted guide to setting up a PHP installation that can work with both the Symfony framework and the doctrine functionality on a Dreamhost server.

Lately I've been experimenting with Doctrine on a few projects. It does have some requirements, including the PDO layer of PHP 5.2. Things didn't work right off the bat on Dreamhost (which I still use for non-critical things), so I opted to build my own php.

The post is basically a cut and paste of a handy "install all" script you can customize to match your installation preferences.

In an effort to somewhat unify the authors of the wide range of PHP database abstraction layers out there in the community, Lukas Smith has proposed a "doctrine miling list" for the discussion of things "like best practices, new discoveries, challenges, etc".

Now I am hoping that all of you are reading this. I know quite a few of you pretty well already (John, Hans, Manuel etc.). [...] So please everybody come out of the woodwork, send me a mail or post a comment.

While I think its fine for end users to also join the list, the goal is not to create a list for end users to ask questions, but more for people who actively develop database abstraction layers. End users should better go to the respective mailing lists.

Ian P. Christian has already stepped up to the plate and is offering a mailing list that you, the database abstraction developer can subscribe to - mailto:phpdbabstraction+subscribe@lists.pengus.net. Be sure to check out the comments for more great discussion.