Hi Davey,
Thanks so much for your enthusiasm. I think you misunderstood the
intent of my email. The code in the DbTable-09 branch is the
implementation that will be used in the ZF 1.0 release. If you
want to
develop your ActiveRecord prototype for Zend, please write a formal
proposal in our wiki format and it will go through the usual review
process. Some of your work may be approved for inclusion in a future
release of Zend Framework. The formal proposal template can be
found at
the following URL:
http://framework.zend.com/wiki/display/ZFPROP/Home
Bill Karwin
-----Original Message-----
From: Davey Shafik [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 07, 2007 3:15 AM
To: Bill Karwin
Cc: Zend Framework
Subject: Re: [fw-general] ActiveRecord patch
Bill,
First off, thank you for such a detailed comparison, this is great!!
I'll go through your list and say what I would like to bring to
Zend_Db_ActiveRecord,
and maybe we can move some of your work over and therefore have the
name people expect
and provide a good implementation :)
The implementation in the branch:
- The find() method always returns a Rowset object (see ZF-21).
Good
because it's easy to call exists() after find().
I agree on the Row Vs Rowset, I never *really* liked it :)
- Supports multi-column primary keys.
Honestly, I've never used this, so I missed this from AR, would love
to see it moved in
- No usage of inflectors.
We could allow both?
- No object vars for searching.
I could easily add a cleanup method, or perhaps you could pass a Row
with the
vars to find() ? I think both would be good :)
- Supports any number of custom Row and Rowset classes per Table
class.
Great, I'd like to see this, but automated use of ARClass_Row(Set)
would be
great too
- Supports queries against related tables, e.g. parent table,
dependent
table, many-to-many table. All queries support multi-column keys.
Obvously needs adding
- Table class supports custom _insert(), _update(), _delete()
filtering.
I'm not sure what this would be used for, but lets bring it over :)
- Table relationship query methods can be either magic or non-magic
(non-magic is useful for tool support).
This would be good too
Your patch has a lot of good ideas, but there are some places where
you
and I disagree:
- I don't think the find() method should return two different class
types depending on the arguments.
Agreed
- I don't care for inflectors, or any manipulation of SQL
identifiers.
The use is minimal, lets remove it :)
- I prefer declaration of metadata, instead of imposing schema
conventions on developers. There are plenty of frameworks that
impose
conventions, which is great for new projects where the developer
has the
freedom to design the database schema. But Zend_Db could gain a
very
valuable differentiator if it works with an existing database
schema.
I already have plans for this, and I agree, it should be possible to
*easily*
wrap AR around an existing table that doesn't conform to our "norm",
and
as I mentioned elsewhere, the way I would like to do this, is
aliasing, that
allows your tables to have a consistent AR API regardless of the
actual
schema beneath.
This is very important to me, actually, that the AR whilst it has a
lot of
voodoo, should be easily overridden internally, and still provide
the same API when used.
- Davey
On Mar 7, 2007, at 4:13 AM, Bill Karwin wrote:
Hi Davey,
I took a good look at your patch for a prototype ActiveRecord
implementation.
You might want to take a look at the implementation currently in
branch
"DbTable-09". I just committed a doc section for it today:
http://framework.zend.com/fisheye/browse/~raw,r=3781/Zend_Framework/
bran
ch/DbTable-09/documentation/manual/en/module_specs/Zend_Db_Table-
Relatio
nships.xml
The implementation currently in the branch actually shares a lot of
features with your implementation. Here are some differences (not
necessarily a complete list):
Your implementation:
- find() method returns a Row or Rowset object, depending on
whether you
give 1 arg or > 1 arg.
- findAll() and findFirst() methods support Boolean operators for
combining the array of where conditions.
- Supports a single custom Row and Rowset class per ActiveRecord
class,
custom Row and Rowset classnames must be based on ActiveRecord
classname.
- Primary keys limited to a single column.
- Supports object vars for searching (how does one reset the object
vars
back to an initial state?)
- "Roll back" (i.e. reset) Row members to clean data.
- Supports custom methods in Row per column, for filtering values
during
__set().
- Uses inflectors to pluralize/singularize during the table
relationships query methods.
The implementation in the branch:
- The find() method always returns a Rowset object (see ZF-21).
Good
because it's easy to call exists() after find().
- Supports multi-column primary keys.
- No usage of inflectors.
- No object vars for searching.
- Supports any number of custom Row and Rowset classes per Table
class.
- Supports queries against related tables, e.g. parent table,
dependent
table, many-to-many table. All queries support multi-column keys.
- Table class supports custom _insert(), _update(), _delete()
filtering.
- Table relationship query methods can be either magic or non-magic
(non-magic is useful for tool support).
Your patch has a lot of good ideas, but there are some places where
you
and I disagree:
- I don't think the find() method should return two different class
types depending on the arguments.
- I don't care for inflectors, or any manipulation of SQL
identifiers.
You get into trouble if your database contains both spellings, e.g.
Dog
and Dogs. Or if the RDBMS uses case-sensitive identifiers, but the
framework is trying to apply camelcasing. The only safe thing to
do is
to use the spelling of SQL identifiers that the RDBMS uses.
- I prefer declaration of metadata, instead of imposing schema
conventions on developers. There are plenty of frameworks that
impose
conventions, which is great for new projects where the developer
has the
freedom to design the database schema. But Zend_Db could gain a
very
valuable differentiator if it works with an existing database
schema.
Regards,
Bill Karwin
-----Original Message-----
From: Davey Shafik [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 06, 2007 1:05 AM
To: Bill Karwin
Cc: Zend Framework
Subject: Re: [fw-general] Zend Framework 0.9 code freeze schedule
Bill,
Yes, I did look at the proposals. I have also done as promised and
written a fully fledged ORM :)
I have attached the files, they will unpack directly in the folder
they are in, and should be placed
in incubator/Zend/Db/
The ORM features as follows:
* Inflection based config, i.e. class Dogs extends
Zend_Db_ActiveRecord { } == table "dogs"
* Advanced "Find" methods:
- find($id)
- find($id, $id2, $id*)
- $obj->id = $id; $obj->find(); $obj->name = "foo";
$obj->find();
- findAll(array('column' => 'value'), (AND|OR))
- $obj->name = "bar"; $obj->findAll();
- findFirst(...) - same as findAll() but only returns a single
row
* Ability to override _setUp() method to customize table name and
PK
column name (i.e. not inflection/reflection based)
* Smart save() method will UPDATE or iNSERT as needed.
* Ability to use 1:1 and 1:MANY relationships
- $row->getFoo() = 1:1 using class "Foos"
- $row->getAllFoos() = 1:MANY using class "Foos"
* Ability to filter data when setting on the record, by doing:
class Foos_Row extends Zend_Db_ActiveRecord_Row {
function name($value)
{
return ucwords($value);
}
}
$foos_row_instance->name = "davey shafik"; // will save as
"Davey
Shafik"
* Ability to rollback to the original row data, or to last save()
call
$row->rollback();
* Duplicate rows using:
$duplicate = clone $original;
$duplicate->save();
And all this in just 584 LOC (including comments and whitespace :)
The only thing I would like to add, is the ability to pre-fetch
relationships using JOINs by setting
an option and looking for $this->*_id - then the getFoo() and
getAllFoos() would just use the already
fetched data.
There is an ActiveRecordExample.php in the zip file, and I also
attached a SQL dump of the DB I'm using
- Davey
