Zend Db 2.0 Kicks Off
Ralph Schindler has started the ball rolling on requirements for Zend Db for Zend Framework 2.0. He announced on the ZF Contributors mailing list:
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.
I worked on Zend_Db during the push to Zend Framework 1.0, so I was interested to see what the goals are for the next major revision.
This is promising. Lots of apps need to use multiple database servers transparently. Zend Db should support a Composite that maps queries to multiple Db objects, delegating using policies defined by the developer.
This is tricky. The risk is the one will run afoul of the YAGNI principle, creating plugin hooks that virtually no one needs. It’s a good time for the developer community to step up and document compelling use cases. Everyone should instantly recognize how important and useful it would be to have a plugin hook RIGHT THERE.
I.e., decouple the connection adapter from query abstraction features. Decoupling is often good, but too much of a good thing can make a system harder to use. Why exactly would one need to do this? Do we need to mix and match an Oracle connection with a MySQL query abstraction class?
This gets to a more general guideline about writing software requirements documents: the justification for a feature is not the absence of that feature. The requirements need to be more clear about the problem to be solved, instead of any particular solution.
Addition of DDL query abstraction
This is very hard. First, DDL varies between vendors even more than DML varies. I put a lot of work into supporting pseudokeys in a vendor-neutral way. Don’t get me started on data types; there’s almost no single data type that’s supported by every RDBMS vendor, not even INTEGER.
Second, vendor-proprietary DDL features are important. Think of special index types, table partitioning, storage engine options, or fulltext search functions. There is very little commonality between vendors in these features, but when you need them, you really need them.
Third, do DDL operations really need to be run from PHP applications (besides phpMyAdmin)?
Addition of a Metadata sub-component
This is a good idea. Not that it’s 2010, we should be able to rely more on standard system tables to tell us more about the schema. Also you shouldn’t have to wire related objects together by assigning their pseudokeys yourself, you should just add one object as a dependent of another, and the objects would consult their metadata to know how they’re related.
However, I recommend strongly: eliminate cascading update/delete in PHP code. I regret implementing this. The RDBMS engine is the only place cascading logic can be implemented while preserving data integrity.
Separate Table & Row Gateway into sub-components of their own
This is another solution in search of a justification. Anyone who uses an ORM for long realizes that it’s a leaky abstraction; you need to write hand-crafted SQL more often than advocates of ORM frameworks will admit. The Table gateway is for operations on one table. Many ordinary queries operate on multiple tables. Making the Table class be the sole provider of insert(), update(), and delete() operations creates an awkward coupling between those operations and a single table.
Better testability in the Unit Tests
Yes indeed. Testing has come a long way in the past three-plus years. It’s true that much of the unit testing of Zend Db classes should be done in isolation (as unit testing should be), using test doubles such as mocks and stubs.
Test setup is another justification for DDL abstraction in Zend Db, but this would be a lot of work for very little gain. It would be far easier to load vendor-specific SQL scripts through the vendor’s client.
I wrote the infamous Zend Db unit testing framework out of desperation to have some way to run the same set of tests against all supported vendors of RDBMS. You need to run tests against live databases. I can’t emphasize this enough. I found and fixed dozens of bugs during development of Zend Db, that were bugs only for one database vendor.
Base Plugins / Type Converter
The problem with type converters that map SQL data types to native PHP types is that some types supported by SQL that can’t map to native PHP types. The best examples are 64-bit integers or unsigned integers. Some SQL data types can only map to PHP strings.
What about some of the long-running feature requests for Zend Db, like stored procedures, character sets, and support for queries that can’t run as prepared statements? What about clarifying the difference between a Model and a data layer?
I saw in this first pass at Zend Db 2.0 requirements a lot of implementation plans but not so much requirements as I would define them. I blogged about this when Matthew Weier O’Phinney wrote a higher-level set of goals for Zend Framework 2.0 some months ago.
Basically, the architecture changes are interesting only to a rarefied audience. But you can’t pitch a product based on how it’s architected or implemented. You pitch a product based on what users can do with it, and what problems it solves. What problems do users of Zend Db have, and how will they use Zend Db 2.0 to solve those problems?