Re: [fw-general] Re: [fw-db] Zend_Db_Table concrete instantiation
-- Mon Zafra mon...@gmail.com wrote
(on Thursday, 16 July 2009, 11:35 AM +0800):
That's neat. I've always wondered why Zend_Db_Table is an abstract class
extending another abstract class while not adding any new methods.
Originally, Zend_Db_Table was abstract itself. At some point, we started
using the naming convention of _Abstract for abstract classes (this is
changing now, due to preparation for usage of namespaces), and
Zend_Db_Table_Abstract was created; to keep backwards compatibility,
Zend_Db_Table was kept, but made to extend Zend_Db_Table_Abstract.
An interesting thing is that Zend_Db_Table_Abstract has allowed you to
pass in the table name and primary key via the constructor -- but with
no concrete class, the use case has been largely overlooked.
Additionally, while that use case can be nice for one-off stuff, it
doesn't allow you to re-use such instances with related tables. What
Ralph has done is add support for creating a table definition, which
allows precisely this use case. It's also flexible enough that you can
mix and match generic instances with concrete instances of your own.
On Wed, Jul 15, 2009 at 9:49 PM, Ralph Schindler ralph.schind...@zend.com
wrote:
Hello all!
I have commited to trunk a new feature for Zend_Db_Table that will be in
ZF
1.9. That feature is the ability to use concrete instantiation on tables.
What does that mean? It means this is possible:
$authorTable = new Zend_Db_Table('author');
$authors = $authorTable-fetchAll();
foreach ($authors as $author) {
echo $author-id . ': '
. $author-first_name . ' '
. $author-last_name . PHP_EOL;
}
On the more complex side, you are able to define a definition that would
house all the same rules you previously had to define your Zend_Db_Table
inherited classes with.
Without going into the gory details, please see this url below for all of
the working use cases I have attempted to solve:
http://framework.zend.com/svn/framework/standard/branches/user/ralph/
ZendDbTable/scripts/
You are free to check out that folder from svn, and run and play with
those
scripts. There is a complete sqlite database, and the bootstrap for that
mini set of script will recreate the sqlite file database on each run.
The only use case which is deprecated as of 1.9 will be if you are
extending Zend_Db_Table (not Zend_Db_Table_Abstract), and are attempting
to
instantiate the class via a string, where the string represents the key
name in the registry of the database adapter. Since Zend_Db_Table has
been
deprecated since 0.9, I don't this should be a problem for anyone.
Please test out this new feature, and report back any issues to me.
Thanks Happy ZF'ing!
-ralph
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
[fw-general] Re: [fw-db] Zend_Db_Table concrete instantiation
That's neat. I've always wondered why Zend_Db_Table is an abstract class
extending another abstract class while not adding any new methods.
-- Mon
On Wed, Jul 15, 2009 at 9:49 PM, Ralph Schindler
ralph.schind...@zend.comwrote:
Hello all!
I have commited to trunk a new feature for Zend_Db_Table that will be in ZF
1.9. That feature is the ability to use concrete instantiation on tables.
What does that mean? It means this is possible:
$authorTable = new Zend_Db_Table('author');
$authors = $authorTable-fetchAll();
foreach ($authors as $author) {
echo $author-id . ': '
. $author-first_name . ' '
. $author-last_name . PHP_EOL;
}
On the more complex side, you are able to define a definition that would
house all the same rules you previously had to define your Zend_Db_Table
inherited classes with.
Without going into the gory details, please see this url below for all of
the working use cases I have attempted to solve:
http://framework.zend.com/svn/framework/standard/branches/user/ralph/ZendDbTable/scripts/
You are free to check out that folder from svn, and run and play with those
scripts. There is a complete sqlite database, and the bootstrap for that
mini set of script will recreate the sqlite file database on each run.
The only use case which is deprecated as of 1.9 will be if you are
extending Zend_Db_Table (not Zend_Db_Table_Abstract), and are attempting to
instantiate the class via a string, where the string represents the key name
in the registry of the database adapter. Since Zend_Db_Table has been
deprecated since 0.9, I don't this should be a problem for anyone.
Please test out this new feature, and report back any issues to me.
Thanks Happy ZF'ing!
-ralph
[fw-general] Re: [fw-db] Zend_Db_Table
On 13/10/2006, at 7:42 AM, Abu Hurayrah (FW) wrote:
Ooohthis is looking good (after reading the explanation
here: http://framework.zend.com/wiki/display/ZFMLGEN/mail/1625). I
would really like to see this going hand-in-hand with my previous
proposal of making Zend_Db_Table_Rowset an implementation of the
ArrayAccess interface. Then you could have the individual elements
of the Rowset be instances of your extended Zend_Db_Table_Row
object...
Am I proposing insanity?
Well... maybe? :p
FWIW I am using this exact code in a project currently nearing
production and it is working insanely well! I know that in-database
joins work well for 'flat' views of data, but this proposed
functionality makes manipulating my business models so much more
flexible and intuitive.
With this enhancement and the removal of camelcaps fieldnames the DB
libraries are getting close to (IMO) the right balance of simplicity
and flexibility.
My other quick set of wishlists would be:-
- Allowing a Zend_Db_Table to modify the database structure on one or
more columns.
e.g.
$table = new Mytable;
$table-updateColumn('description', 'varchar', array('length' =
255));
$table-addKey('id', array('type' = 'primary'));
$table-alter();
Perhaps this could be an extension of Zend_Db_Table
(Zend_Db_Table_Schema?) that provides table manipulation methods only?
- Allowing comparisons of Zend_Db_Table objects to view discrepancies
in definitions. Much like 'diff' except you can resolve either column
definitions, data or both. The 'source' table acts as the blueprint
and the target is the one that gets updated. This would be truly
invaluable in an environment where multiple test/development
databases can start to pile on structural differences to the
production database. Could belong above?
- pre Insert hooks for Zend_Db_Table / Update for Zend_Db_Table_Row
(much like the project that Gavin provided a link to) that can
manipulate array data before the operation. Useful for timestamps,
removing non-existent column keys, etc.
--
Simon Mundy | Director | PEPTOLAB
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654
4124
http://www.peptolab.com
