Zend Framework: Zend_Db_Gateway Component Proposal
| Proposed Component Name | Zend_Db_Gateway |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Db_Gateway |
| Proposers | My E-mail Address |
| Revision | 1.1 - 22 January 2008: Proposal created. (wiki revision: 10) |
Table of Contents
1. Overview
Zend_Db_Gateway is an interface abstraction for creating Zend_Db_Table oriented queries.
2. References
- Zend_Db_Select
- Zend_Db_Table
3. Component Requirements, Constraints, and Acceptance Criteria
Current Zend_Db_Table implementation provides a limited interface for database data retrieval. In most real world scenarios, queries often require several tables to be joined, as related data is split for normalization's sake, and also for specific columns to be retrieved (creating 'views'). This component provides an interface to creating complicated queries - reducing the overhead of writing them by hand, relies on Zend_Db_Table reference maps to define table relationships and abstracts explicit table names.
- This component will provide an interface for query composition.
- This component will allow the creation of 'views' (partial column retrieval).
- This component will abstract table names so they shall not be declared explicitly.
- This component will use Zend_Db_Table reference maps for defining table relationships.
- This component will not be coupled to Zend_Db_Table, despite borrowing design features from it.
- This component will use Zend_Db_Select as a lower-level query composition tool.
4. Dependencies on Other Framework Components
- Zend_Db_Select
- Zend_Db_Adapter_Abstract
5. Theory of Operation
The class provides a base interface for composing cross table queries (joins) that is intended to be abstracted further into meaningful method names by extending classes. The extending methods can than be used be reused to create different query composition combinations.
When instantiated, this component is provided with a instance of Zend_Db_Adapter, a table name for which this instance will act as gateway, and an optional reference map.
Class API methods share a single Zend_Db_Select object (class member), which can be reset (full/partial) on demand.
Query process begins with an initialization method or alternatively a Zend_Db_Select instance may be provided with pre-configured query options.
Table names are fetched from their corresponding table classes, and then cached for the lifetime of the object.
6. Milestones / Tasks
- Milestone 1: [DONE] Submit proposal
- Milestone 2: [DONE] Provide documented working prototype and use cases
- Milestone 3: Re-design based on provided community feedback
- Milestone 4: Provide unit tests.
- Milestone 5: Proposal accepted into incubator.
7. Class Index
- Zend_Db_Gateway
8. Use Cases
UC 01
Files is a file management class for a web application - it allows users to upload files, organize files by folders, share files to other users and to have a basic versioning mechanism.
Apart from the file itself, all relevant data is stored in the database in four distinct tables:
user_files: Contains file details, including hash, title, description and an ID of the uploading user (owner).
user_folders: Contains file folders details. File folders have names, a unique numeric ID and a parent ID for creating a tree-like hierarchy.
users_to_files: Provides many-to-many relationship between files and users.
user_file_versions: Is similar to user_files and contains different versions of specific files from user_files.
Building views from data retrieved from all four tables is done in the following manner:
First, extending the Gateway class and creating meaningful and reusable query composition methods:
Views can then be easily created from a Zend_Db_Table extending class: (easy compared to manual query composition)
9. Class Skeletons
Your approach is indeed similar to what is currently used by the Zend_Db_Table for table relationship management. I see no problem adding a magic method that can automatically inflect calls to the basic 'with' and 'by' methods, as the end result is the same after all. You can also see that the syntax is very similar to my fluent interface version - it is just a matter of personal preference.
Personally, when writing code I rely much on the auto-complete feature of my IDE (Zend Studio) to expedite and automate code generation which can not be done with magical methods, forcing me to have the documentation at hand when using such methods as I have a pretty bad memory. Also, in the spirit of performance, I tend to rely less on magical methods when the benefit is not obvious.
I see no problem offering both approaches and giving the developer options when choosing his implementation.
I might be if I knew that the proposals are again being considered. Since I submitted it half a year ago I made several changes based on accumulated experience, so I'd need to update the proposal to support it. Are you guys pushing proposals currently?
We have been reviewing them since the new proposal process was rolled out. Currently, our queue is empty (some of the proposals that have a recommendation haven't been updated by their Zend Liaisons yet). But to be clear, it is largely the author's responsibility to push the proposal; your liaison takes responsibility only after you've moved the document through 'Ready for Review' to 'Ready for Recommendation', where it is picked up by the Zend team. Please refer to this doc for a full rundown of the new proposal process: http://framework.zend.com/wiki/display/ZFPROP/Proposal+Process.
,Wil
I'm aware of the proposal process. I tagged it back then (6 months ago) as ready for review but haven't seen any progress... this is why I am asking.
OK, so if it's ready for review, go ahead and move it to the 'Ready for Review' section. It wouldn't hurt to announce it on the list, even if you have done that before. You'll get more community comments in that section, especially if you announce on the list.
,Wil
ZF Home Page
Code Browser
Wiki Dashboard
Hi Eran
This makes the idea much clearer to me, and I can see the really benefits. One thing that did come to mind was that perhaps rather than creating a whole new Gateway component another option could be building upon the existing Zend_Db_Table_Select object.
For example, many of the 'order', 'with' and 'by' methods in your business models could just as easily reference data from within the Zend_Db_Table definitions, in a similar way to the existing structure. We could build upon those and make the table-specific select() object work a bit harder.
E.g. Using your existing UC Table as a starting point:-
could be expressed as
I don't mean to run over your idea but I'd like to see if there's any opportunities to use existing and closely-matching code.