Re: [CakePHP : The Rapid Development Framework for PHP] #6276: afterFind() called twice / documentation does not match behaviour

[CakePHP : The Rapid Development Framework for PHP]

#6276: afterFind() called twice / documentation does not match behaviour
--+-
Reporter:  nemosoft   | Owner:   
Type:  RFC|Status:  new  
Priority:  Medium | Milestone:  1.2.x.x  
   Component:  Model  |   Version:  1.2 Final
Severity:  Normal |Resolution:   
Keywords:  afterFind primary data corruption  |   Php_version:  PHP 5
Cake_version:  8120   |  
--+-
Comment (by Pichan):

 Still nothing? I'd at least like an official opinion on this ticket.[[BR]]
 Is it supposed to do that? Is the code wrong or are the docs wrong?[[BR]]
 I have no idea what kind of problems the devs are facing elsewhere since
 this is my first time using trac here but at least from my point of view
 cake acting like this is an annoyance. A minor one but still one.[[BR]]
 At least how I see it, having to identify data only by it's structure
 should be avoided.

-- 
Ticket URL: 
CakePHP : The Rapid Development Framework for PHP 
Cake is a rapid development framework for PHP which uses commonly known design 
patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. 
Our primary goal is to provide a structured framework that enables PHP users at 
all levels to rapidly develop robust web applications, without any loss to 
flexibility.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"tickets cakephp" group.
To post to this group, send email to tickets-cakephp@googlegroups.com
To unsubscribe from this group, send email to 
tickets-cakephp+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/tickets-cakephp?hl=en
-~--~~~~--~~--~--~---

Re: [CakePHP : The Rapid Development Framework for PHP] #6276: afterFind() called twice / documentation does not match behaviour

[CakePHP : The Rapid Development Framework for PHP]

#6276: afterFind() called twice / documentation does not match behaviour
--+-
Reporter:  nemosoft   | Owner:   
Type:  RFC|Status:  new  
Priority:  Medium | Milestone:  1.2.x.x  
   Component:  Model  |   Version:  1.2 Final
Severity:  Normal |Resolution:   
Keywords:  afterFind primary data corruption  |   Php_version:  PHP 5
Cake_version:  8120   |  
--+-
Comment (by eimermusic):

 And BTW, I posted an update to the cookbook mentioning that afterFind
 receives different data-structures in different cases. It was rejected
 since it could apparently confuse people to know the details of how
 afterFind works.
 [[BR]]
 
 http://book.cakephp.org/revisions/view/5077/afterFind[[BR]]
 Supplied examples seem too specific for a general topic. Mention of
 different cases could be made, but too many examples might prove confusing
 for every-day users.
 

-- 
Ticket URL: 
CakePHP : The Rapid Development Framework for PHP 
Cake is a rapid development framework for PHP which uses commonly known design 
patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. 
Our primary goal is to provide a structured framework that enables PHP users at 
all levels to rapidly develop robust web applications, without any loss to 
flexibility.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"tickets cakephp" group.
To post to this group, send email to tickets-cakephp@googlegroups.com
To unsubscribe from this group, send email to 
tickets-cakephp+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/tickets-cakephp?hl=en
-~--~~~~--~~--~--~---

Re: [CakePHP : The Rapid Development Framework for PHP] #6276: afterFind() called twice / documentation does not match behaviour

[CakePHP : The Rapid Development Framework for PHP]

#6276: afterFind() called twice / documentation does not match behaviour
--+-
Reporter:  nemosoft   | Owner:   
Type:  RFC|Status:  new  
Priority:  Medium | Milestone:  1.2.x.x  
   Component:  Model  |   Version:  1.2 Final
Severity:  Normal |Resolution:   
Keywords:  afterFind primary data corruption  |   Php_version:  PHP 5
Cake_version:  8120   |  
--+-
Comment (by eimermusic):

 Last year I detailed the differences in data I had found. It is available
 in the thread below. The thread also contains a method for AppModel that
 helps to hide these inconsistencies from the rest of your app (use Matt's
 version from December). As for the double-calls with the same data I still
 use custom checks in my afterFinds to not unserialize / decrypt twice.
 [[BR]]
 [[BR]]
 [http://groups.google.com/group/cake-
 php/browse_thread/thread/32ab9f8baed4a05a]

-- 
Ticket URL: 
CakePHP : The Rapid Development Framework for PHP 
Cake is a rapid development framework for PHP which uses commonly known design 
patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. 
Our primary goal is to provide a structured framework that enables PHP users at 
all levels to rapidly develop robust web applications, without any loss to 
flexibility.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"tickets cakephp" group.
To post to this group, send email to tickets-cakephp@googlegroups.com
To unsubscribe from this group, send email to 
tickets-cakephp+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/tickets-cakephp?hl=en
-~--~~~~--~~--~--~---

Re: [CakePHP : The Rapid Development Framework for PHP] #6276: afterFind() called twice / documentation does not match behaviour

[CakePHP : The Rapid Development Framework for PHP]

#6276: afterFind() called twice / documentation does not match behaviour
--+-
Reporter:  nemosoft   | Owner:   
Type:  RFC|Status:  new  
Priority:  Medium | Milestone:  1.2.x.x  
   Component:  Model  |   Version:  1.2 Final
Severity:  Normal |Resolution:   
Keywords:  afterFind primary data corruption  |   Php_version:  PHP 5
Cake_version:  8120   |  
--+-
Comment (by deizel):

 Please bear in mind I have done next to no research before posting this:

 Just an observation, but without the second pass it would make it
 difficult for someone to merge two records together in an afterFind()
 callback.

 I can't immediately think of a solid reason why someone might want to do
 this, but if there was a flag similar to $primary - one could check for
 this during the second pass, and this would remain a possibility.

 Alternatively, the first pass(es) could be scrapped, and the developer
 could implement record-looping himself as is documented:

 {{{
 function afterFind($results, $primary) {
 foreach ($results as $result) {
 $result = $this->_combineNames($result);
 $result = $this->_calculateTotal($result);
 }
 return parent::afterFind($results, $primary);
 }
 }}}

 Apologies if I am oversimplifying things here - just food for thought -
 feel free to correct me on anything I have overlooked.

-- 
Ticket URL: 
CakePHP : The Rapid Development Framework for PHP 
Cake is a rapid development framework for PHP which uses commonly known design 
patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. 
Our primary goal is to provide a structured framework that enables PHP users at 
all levels to rapidly develop robust web applications, without any loss to 
flexibility.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"tickets cakephp" group.
To post to this group, send email to tickets-cakephp@googlegroups.com
To unsubscribe from this group, send email to 
tickets-cakephp+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/tickets-cakephp?hl=en
-~--~~~~--~~--~--~---

Re: [CakePHP : The Rapid Development Framework for PHP] #6276: afterFind() called twice / documentation does not match behaviour

[CakePHP : The Rapid Development Framework for PHP]

#6276: afterFind() called twice / documentation does not match behaviour
--+-
Reporter:  nemosoft   | Owner:   
Type:  RFC|Status:  new  
Priority:  Medium | Milestone:  1.2.x.x  
   Component:  Model  |   Version:  1.2 Final
Severity:  Normal |Resolution:   
Keywords:  afterFind primary data corruption  |   Php_version:  PHP 5
Cake_version:  8120   |  
--+-
Comment (by derkyjadex):

 I am having the same problem here, version 8166.

 I would say that in the associated model, afterFind() should only be
 called once for each result returned, and with the structure given in the
 current documentation. Otherwise the developer would always have to dig
 through layers of arrays for what is always a single result.

 I also see no reason for the second pass. The associated model would have
 to know about the defined associations in the primary model to make any
 use of the extra data. Logic that requires this would be better placed in
 the primary afterFind().

-- 
Ticket URL: 
CakePHP : The Rapid Development Framework for PHP 
Cake is a rapid development framework for PHP which uses commonly known design 
patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. 
Our primary goal is to provide a structured framework that enables PHP users at 
all levels to rapidly develop robust web applications, without any loss to 
flexibility.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"tickets cakephp" group.
To post to this group, send email to tickets-cakephp@googlegroups.com
To unsubscribe from this group, send email to 
tickets-cakephp+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/tickets-cakephp?hl=en
-~--~~~~--~~--~--~---

[CakePHP : The Rapid Development Framework for PHP] #6276: afterFind() called twice / documentation does not match behaviour

[CakePHP : The Rapid Development Framework for PHP]

#6276: afterFind() called twice / documentation does not match behaviour
--+-
Reporter:  nemosoft   |  Type:  RFC   
  Status:  new|  Priority:  Medium
   Milestone:  1.2.x.x| Component:  Model 
 Version:  1.2 Final  |  Severity:  Normal
Keywords:  afterFind primary data corruption  |   Php_version:  PHP 5 
Cake_version:  8120   |  
--+-
 SUMMARY
 [[BR]]
 * With hasMany relations, afterFind() is called twice on the same
 data.[[br]]
 * The example given in the manual for afterFind() will mess up your
 data.[[br]]
 [[BR]]

 DESCRIPTION[[BR]]

 I would like to have your opinion on the following problem I've
 encountered using Model::afterFind(). It is the combination of afterFind's
 behaviour and the documentation in the manual that causes corruption of
 the data that is being read with a hasMany relation.[[BR]]
 [[BR]]

 See the attached example of a simple Tutor/Pupil/Course database. A Tutor
 hasMany Pupils, and also hasMany Courses. When reading in a Tutor, Pupils
 and Courses are automatically read as well, and their data is passed
 through their respective afterFind() functions *twice*. Or rather,
 afterFind() is called once for each individual record (the first pass),
 and once more wtih all data combined (second pass). The problem is that
 the data layout differs subtly between the first and second pass. The
 second pass has the same data one layer deeper; if one follows blindly the
 example given in the manual (http://book.cakephp.org/view/681/afterFind)
 as I did, the data will be messed up during the second pass.[[BR]][[BR]]


 The first pass formats data like this:

 {{{
 $results = array { [0] { [Pupil] { [id], [name], [tutor_id] } } }
 }}}

 This is called for each record retrieved from the database.[[BR]]


 The second pass uses all data in a combined format:

 {{{
 $results = array { [0] { [Pupil] { [0] { [id] [name] [tutor_id] }, [1] {
 ... }, [2] { ... } } } }
 }}}

 In both cases, the $primary boolean is set to false.
 [[BR]]
 [[BR]]


 There are multiple issues with this behaviour:

 - Essentially the same data is passed twice through afterFind(); this is
 inefficient and can introduce side effects (see below)[[BR]]
 - It both cases $primary is false, but the data is in a different layout.
 Moreover, it does not match the documentation!
 [[BR]][[BR]]

 Others have noticed this anomolous behaviour, see for example
 [http://groups.google.com/group/cake-
 
php/browse_thread/thread/c83e5f40ac861caa/1d88bdb31fa3d12f?lnk=gst&q=afterFind#1d88bdb31fa3d12f
 this Google Groups post] and [http://groups.google.com/group/cake-
 
php/browse_thread/thread/4b10a1d5ccd468d9/fb225acbdac9109d?lnk=gst&q=afterFind#fb225acbdac9109d
 this one].
 [[br]]
 [[br]]



 Some people have suggested solutions, like [http://groups.google.com/group
 /cake-
 
php/browse_thread/thread/d1eea174c3143d83/6bada5f9fce6f714?lnk=gst&q=afterFind#6bada5f9fce6f714
 this one] but in that case the data is processed twice. This could lead to
 weird data behaviour, for example if one converts dates from database to
 human format by string manipulation, concatenates strings, adds numbers,
 etc. I've used a rot13() function in my example.
 [[br]]
 [[br]]

 I think the behaviour stems from fixes for another problem where
 afterFind() was not called at all for recursive retrievals (for example,
 see changeset 7347). Now it's being called too many times.[[br]][[br]]

 My questions are:[[br]]
 * Is the observed behaviour of calling afterFind() twice intended? If so,
 what's the reason behind passing different data layouts?[[br]]
 * Could somebody please update the documentation for afterFind()? Either
 mention that the function is called twice with hasMany relations, or fix
 the example so that it won't work on the second pass.[[br]][[br]]

 I'm of the opinion that the second call to afterFind() is an error. It
 would make sense to process each record as it is being retrieved, but not
 do it again on the combined data set. The former would also eliminate the
 distinction between primary and non-primary retrievals, since the data
 layout is the same now (my observation).[[br]][[br]]

 Of course, a workaround would be to ignore the second pass, but I don't
 think that burden should be placed on the developer...

-- 
Ticket URL: 
CakePHP : The Rapid Development Framework for PHP 
Cake is a rapid development framework for PHP which uses commonly known design 
patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. 
Our primary goal is to provide a structured framework that enables PHP users at 
all levels to rapidly develop robust web applications, w