On the TutsPlus.com site they've posted a tutorial showing you how to use a CRUD generator tool to automatically generate some of the create, read, update, and delete functionality for your application.

In this article, we’re going to review PDO CRUD - a form builder and database management tool. PDO CRUD helps you build forms for your database tables with just a few lines of code, making it quick and easy to bootstrap a database application.

[...] Today, we’re going to discuss the PDO CRUD tool, available at Code Canyon for purchase at a very reasonable price. It’s a complete CRUD builder tool which allows you to build applications by just providing database tables and by writing a few lines of code.

It works with multiple database back-ends, including MySQL, Postgres and SQLite. In this article, we’ll see how to use PDO CRUD to build a CRUD system with the MySQL database back-end.

They then walk you through the installation and configuration of the tool, defining options about the host, username, and password for the database. It then helps you create two tables that will be used as sources: employee and department. Once these are defined, you can then use the web frontend to perform CRUD operations on these tables without having to write any custom code. It also lists out some of the additional features including searching, pagination and bulk export.

The post goes on to talk about how to make modifications to how the system works with the data in the tables (like field types), creating join views and customizing the options for other tool features.

Rob Allen has continued his series of posts covering the use of PHP on the OpenWhisk platform. In his latest tutorial he shows how to use dependency injection for use in "non-trivial PHP applications".

Any non-trivial PHP applications use various components to do its work, from PDO though to classes from Packagist. It’s fairly common in a standard PHP application to use Dependency Injection to configure and load these classes when necessary. How do we do this in a serverless environment such as OpenWhisk?

This question comes up because we do not have a single entry point into our application, instead we have one entry point per action. If we’re using Serverless to write an API, then we probably

He uses a common connection type - PDO to a database - to illustrate a method for injecting dependencies in a serverless application. In his example, he starts with a simple script that returns a set of "todo" items from the database (with the PDO connection code embedded in it). Using dependency injection is a better way to manage that PDO connection so he shows how to update it to use the Pimple DI container and inject it via the constructor to make it available to the rest of the application.

Johannes Schlüter has a post to his site detailing the handling of types in PHP and MySQL and how they might act differently than expected in some situations.

Since PHP 7.0 has been released there's more attention on scalar types. Keeping types for data from within your application is relatively simple. But when talking to external systems, like a database things aren't always as one eventually might initially expect.

He talks about MySQL types and how they relate to the "network protocol" being used, converting everything to strings. He includes a few examples of hinting on the results, one where an integer is expected/string provided and another where a string was type hinted but an integer was returned. He points out that sometimes this is a limitation of what PHP can handle, not always what MySQL returns. He also includes other examples of returning decimals - sometimes as a number value and others as a string.

This leaves the question whether you should disable the emulation in order to get the correct types. Doing this has some impact on performance characteristics: With native prepared statements there will be a client-server round-trip during the prepare and another round-trip for the execute.

On the PHPDelusions.com site there's a post that compares the functionality of mysqli to PDO and looks at the differences in their overall usability.

By no means I am going to say that mysqli is worse than PDO. Mysqli is an excellent extension, with many specific features. But it's just not intended to be used directly. To make it usable, one have to always wrap it into a helper library, to reduce the enormous amount of code that otherwise have to be written by hand.

[...] But for the average PHP/MySQL user, standard APIs are the only known methods for database interaction. Thus they tend to use both extensions right in the application code, without any intermediate wrapper around. For such a use PDO is an indisputable winner, and I'll show you why.

The post then breaks it down into sections comparing the functionality between the two database access methods:

• Named placeholders
• General inconvenience in binding
• Getting single column value
• Getting multiple rows
• Binding unknown number of parameters
• Compatibility

Of course, all the inconveniences above could be overcame by a good wrapper. This is why if you choose mysqli, you definitely have to use one.

Matthew Turland has a post to his site sharing his experience with the PHPUnit and XHProf combination...and the unfortunate result that made every test fail.

I ran into an issue recently while trying to run PHPUnit tests in an environment using XHProf. Google didn’t prove to be much help, so I thought I’d document the problem and solution here for posterity.

When I ran my tests, each failed with the same cryptic error and no backtrace: "Attempted to serialize unserializable builtin class PDO" The cause was the culmination of two rather unfortunate circumstances.

He shares the two problems that causes this issue - one being XHProf's use of globals (where its PDO connection is stored) and the other is the @backupGlobals setting in PHPUnit that's enabled by default. This makes PHPUnit to try to backup that PDO connection by serializing it but can't, hence the failure. He points out a pull request that aims to fix the issue but recommends disabling the globals backup for the time being if you don't have a need for it.

On the SitePoint PHP blog they have a post that "reintroduces PDO" or as they describe it, the "right way to access databases in PHP". The PDO functionality in PHP provides extra handling around database connections and queries as well as making it easier to connect to multiple types of databases with similar code.

PDO is the acronym of PHP Data Objects. As the name implies, this extension gives you the ability to interact with your database through objects. [...] PHP is rapidly growing, and it is moving toward becoming a better programming language. Usually, when this happens in a dynamic language, the language increases its strictness in order to allow programmers to write enterprise applications with peace of mind.

In case of PHP, better PHP means object-oriented PHP. This means the more you get to use objects, the better you can test your code, write reusable components, and, usually, increase your salary. Using PDO is the first step in making the database layer of your application object-oriented and reusable.

He starts by answering the question most ask about PDO versus mysql/mysqli by pointing out that PDO is more OOP friendly, it allows for parameter binding and the fact that the mysql extension is no longer supported. He shows how to check and ensure PDO is installed on your setup and, if not, how to add it in (for both linux and Windows systems). The tutorial then walks you through using PDO: making the connections to the server, running queries and returning the results. This includes a section on prepared statements and bound parameters and their benefits including SQL injection prevention.

In a post to his site Michelangelo van Dam shows you how to speed up database calls with PDO and iterators in a "no framework" environment.

When you review lots of code, you often wonder why things were written the way they were. Especially when making expensive calls to a database, I still see things that could and should be improved.

When working with a framework, mostly these database calls are optimized for the developer and abstract the complex logic to improve and optimize the retrieval and usage of data. But then developers need to build something without a framework and end up using the basics of PHP in a sub-optimal way.

He points out some of the common issues with a simple approach using just PDO and simple arrays including performance issues. Instead he recommends the use of iterators that wrap a PDO connection and allow for much simpler fetching and iteration of the found results. He includes code examples for a base iterator instance and a way to extend it to get the customized results. He also includes a few benchmarks showing the difference between a foreach loop and this iterator method.

In an article posted to his site Rob Allen shows you how to hook in the OAuth2 authentication for an Apigility-based application with a pre-existing database table structure that may not match the defaults Apigility is looking for.

I have a client that's writing an Apigility API that needs to talk to a database that's already in place. This also includes the users table that is to be used with Apigility's OAuth2 authentication. Getting Apigility's OAuth2 integration to talk to a specific table name is quite easy. [...] However, if you want to use different column names, that's a bit trickier as they are hardcoded in the OAuth2StoragePdo class. To get Apigility's OAuth2 components to look at the correct columns, you create your own OAuth2 Adapter. I chose to extend ZFOAuth2AdapterPdoAdapter which extends OAuth2StoragePdo and go from there.

He includes the code for this extension of the PdoAdapter (a "OAuth2Adapter" class) in the post showing the definitions of the get user, set user and check password methods the OAuth2 flow needs to match users to OAuth sessions. He also includes the code for the "OAuth2AdapterFactory" class that's used to pull the custom PDO adapter class into Apigility and, along with some configuration changes, make it available for use. Then it's just a simple matter of changing the authentication type in the Apigility UI.

Evert Pot was seeing some weird issues with his MySQL BOOL usage via PDO when he upgraded to one of the latest versions (5.6). Thankfully, he's shared his solution to the problem as well as the symptoms he was seeing when it was causing problems.

I recently updated my workstation to run MySQL 5.6.13. It didn't take very long for things to start breaking, and since I couldn't find any other information about this on the web, I figured this may be useful to someone else. The main error that started popping up was: "Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'my_bool' at row 1' in test.php" This exception happens under the condition that you use PDO, prepared statements and booleans.

He includes a small sample script to reproduce the issue and points out the issue - the default casting of prepared values to strings in prepared statements with PDO bound parameters. He shows two "relatively easy solutions" to the problem - either using integers instead of the true/false PHP boolean or specifying a type with the bindValue call.

On the tech.pro site there's a recent tutorial posted showing you a basic way to create an RSS feed using data coming from a database accessed via PDO.

Using an RSS feed on your website is a great way of letting your visitors, search engines or directories get a hand on your content. RSS feeds are common practice on most blog and CMS platforms including Wordpress, Joomla and evenly the newly released Ghost. If you're using a CMS or similar platform, the likelihood is that you don't need to implement an RSS feed yourself. [...] Below you've got the step-by-step process to create anything from the simple, standard-compliant RSS feed - up to the more advanced.

The tutorial shows you how to pull the data from a simple database table (SQL not provided, but pretty easy to figure out(, including example PDO connections for several database types. This data is then manually appended into an XML string to build out the RSS feed correctly. They also talk about implementing the Dublin Core metadata as a way for providing more information about the feed and its contents (including an image and category details).