It's not just Davey's proposal; all proposals must go through the formal proposal process. Especially something like Active Record. Rushing something like that in time for 0.9, or even 1.0, would be a disaster.
Also, once Zend_Db_Table is ironed out, a Zend_Db_ActiveRecord class could probably be built on top of it (after 1.0). Or we may find that it's unnecessary once people actually start using Zend_Db_Table. -Matt > Why are you not being open to Daveys suggestions? For one, would > prefer the AR classes to have the ability to be mapped using meta > data, or to automatically map themselves. > > On Mar 7, 2007, at 2:31 PM, Bill Karwin wrote: > >> 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 >>>> >>>> >> > >
