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 its current version, it'll be able to accomplish only a few basic database operations tasks. Therefore, this fifth article of the series will be focused on enabling the class to fetch database rows by using the LIMIT clause.

They add the LIMIT clause as a part of its own function and its own SQL statement. You define the number of rows to fetch, the table to fetch it from and the offset to start from. The SQL is passed off to their fetchRow statement and the results are returned in an array.

In its current incarnation, this class's functionality is limited, regardless of its decent level of SQL abstraction. Therefore, in this fourth part of the series I'm going to enhance it by making it capable of working with LIKE clauses in a straightforward way.

They look at using LIKE to match values in various columns of the tables and add in a fetchLike method that lets you specify the column to search, the pattern to match on and the table to search in.

Chris notes also that it's a welcome change over to this pre-existing license to reduce the number of licenses that companies would have to change/evaluate.