On the Zend Framework blog today Enrico Zimuel has posted an announcement about the zend-db component including a look at the new release and the future of the component.

Today, we released zend-db 2.9.0! This is our first new feature release in over 18 months, and contains 7 bug fixes, 6 new features, numerous unit test additions, and many documentation improvements.

zend-db is an important component of many PHP projects, and we know that its support is crucial for many people. As such, we allocated a number of weeks to triaging the various open issues and patches (more than 50) to ensure we would provide a stable release.

The post lists out the issues fixed and the features added, linking to the bugs that were files related to each. It then talks about the future of the component, noting that a v3.0 release is expected to come in 2018 and will include a lot of new features. This will help to make working with more modern features of the various databases easier directly from the code (without as much manual query creation or hackery). The post finishes with some thanks to those that contributed to this v2.9.0 release.

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

With the new modular infrastructure in Zend Framework 2, one of the most common questions will indoubitably be how to share a database connection across modules. Here’s a quick explanation of how to share your database connection across multiple modules in a way that can even allow you to use a single connection between ZendDb, Doctrine2, and possibly even other database libraries / ORMs.

He includes the code in the post to configure this application-wide database resource, a "masterdb_pdo" that uses a MySQL backend. This configuration is used to set up the connection in a dependency injection container for later (globalish) use. He also mentions something similar about sharing Doctrine connections with the ZendDb components (using the same DI container approach).

Rob Allen has a tip for the Zend Framework users out there using the Zend_Db module to connect to their database resources - how to do a one to many join with the help of Zend_Db_Table_Select (easier than it sounds).

Let's say that you want to set up a one-to-many relationship between two tables: Artists and Albums because you've refactored my ZF1 tutorial. [...] Assuming you're using Zend_Db_Table, the easiest way is to turn off the integrity check and do a join in a mapper or table method.

He includes a few lines of source to illustrate, calling the "setIntegrityCheck" value to "false" to tell ZF not to worry about the additional join value over to the artists table. The result is a new column value with the artist's name instead of just the ID.

In a new post to his blog Till Klampaeckel looks at something the Zend Framework's Zend_Db component dosen't seem to support - an "IN" on a fetchAll - and how he worked around it.

The IN-clause is only supported when I wrap my statement with Zend_Db_Select, which is something I rarely do. Part of the reason is that I still don't feel comfortable writing my SQL in a DSL which doesn't really do anything besides wrapping a string into an object and IMHO it doesn't add to readability either. And the other reason is that I don't plan to run this import against any other database than MySQL. Which is why I don't see the need for abstraction either.

He shows some failing code where the IN isn't populated correctly when an array is passed in and the warnings that come with it. He solution's pretty simple, though - rewrite the query string before sending it with the correct number of bind locations ("?") for the number of parameters. In the comments, other approaches are suggested including using a simple select() call or tricking the bindings with a special kind of array.

In this latest post to his blog Rob Allen takes a look at a problem he had when installing a project that used SQL Server as its data source - it just didn't work.

A good proportion of the projects my company undertakes end up on Windows servers with IIS and SQL Server and hence we use the SqlSrv PHP extension from Microsoft. We don't host any of these projects ourselves and leave it up to the client's IT department. This is the main reason that we use a database abstraction layer, Zend_Db, in our case as we can swap the underlying database out with less hassle. A couple of weeks ago, I came across a problem when installing our app onto the client's server. It didn't work. This was a surprise as we have a few Windows Server VMWare installations on which we had tested and they had worked fine.

He ultimately boiled it down to an exception from the SQL Server - "String data, right truncation". As it turns out, with the version 2 of the sqlsrv driver, you can't have a field name longer than 30 characters. There's two obvious workarounds - shorten the field name or use a PDO interface. Since one doesn't exist (well, not formally) he created his own you can drop into your application if you have the need.

On PHPRiot.com Quentin Zervaas has posted the latest article in his "Zend Framework 101" series that talks about several of the more well-used components of the framework. This time he take a look at the Zend_Oauth component that allows your application to talk with remove OAuth service.

To demonstrate how to use this component, we're going to create a basic script that allows a user to log in to their Twitter account and post a status update. Twitter is currently phasing out "basic authentication" and requiring all third-party web and desktop applications use OAuth. This article can be used as a starting point for creating (or updating existing) Twitter API apps. We will also be using the Zend_Service_Twitter component, as I covered in a previous screencast.

He talks some about how OAuth works and how to use the component, along with Zend_Db, to create a simple comsumer script that connects to Twitter and posts a message to Twitter as the user that's authenticated.

As is mentioned on the php|architect blog today (from Bill Karwin) the requirements gathering stage for the Zend_Db 2.0 version of the database component for the Zend Framework has started. Ralph Schindler has issued a document talking about some of the issues that have come up in the component's past.

Requirements have been solicited from both community members in various conversations, as well as looking through the issue tracker for feature requests that have been on the backlog due to potential BC breakage. This document reflects those ideas, and it’s now in a position where we’d like to start a discussion on the direction outlined inside it.

Suggested features include things like:

• Pluggable architecture
• Distinct abstractions
• Addition of a Metadata sub-component
• Better testability in the Unit Tests
• Base Plugins / Type Converter

Quentin Zervaas has posted a new tutorial on phpRiot.com today with a quick look at using Zend_Db to pull information out of your database.

In this PhpRiot Snippet I will show you a couple of different ways to fetch data when using the Zend Framework's Zend_Db component. Zend_Db is a useful database abstraction class that comes with the Zend Framework. This article assumes you have already established a database connection and you have tables to select data from.

They show you how to fetch a single value from a table, grab all of the records from a specific column, getting more than one column and grabbing all of the contents of a table and returning them to your script with a "fetchAll" method call.

The Content with Style blog has a gotcha that Zend Framework developers could come across if they're using MySQL pre-5.17:

was getting weird errors when running multiple queries with Zend Framework, that I just couldn't replicate on my local environment. [...] Turns out the server runs MySQL pre 5.17.

This caused a stack trace error where the queries wouldn't run correctly. The solution was (like the error message suggests) turning on query buffering with the "PDO::MYSQL_ATTR_USE_BUFFERED_QUERY" in the PDO connection's parameters. You can find out more information about the parameters you can pass to the adapter in this section on the Zend Framework' Zend_Db manual page.

In response to this older post Ralph Schindler has posted some of his own thoughts on database abstraction layers - they must live!

Interestingly, I can put the vocal proponents of each side of the argument in one of two boxes: a programmer guy box, or a database guy box. For some unknown reason though, they never seem to see eye to eye. [...] Generally speaking of database driven projects, I feel like planning to use a specific vendor up front, knowing its pro's and con's, and tailoring an application to the chosen database's strengths can only help in the long run. Also, I feel that building a database model first before any code, offers many performance and scalability advantages than does code first development.

He notes that, while he agrees on the problems with the "switching databases at any time" problems the other author brings up, he points out that the abstraction layers do have their place. He includes an example of an abstraction layer with the Zend_Db object of the Zend Framework. His sample code shows how it can be used to simplify your interaction with your database.