Update: Well, I decided against using beforeSave/afterSave to write a
manual query call and avoid counterCache...now that I'm a bit more
clear headed, I'm not sure why. Either way, I think I may have found
a solution to fix this in the core, but I need to write some tests and
submit a patch to see if the devs will approve it. This solution may
have a small drawback as the way things work now might be perceived by
some as a bug, and others as a feature...I'm leaning more towards a
missed scenario or test-case and therefore am hoping it'll be
approved. It's just a simple IF statement added to the
updateCounterCache method in model.php...right before the call to
updateAll:
if($this->data[$this->alias][$assoc['foreignKey']] != null){
....(updateAll)...
}
...therefore, it won't update a row's counter on records without a
parent. This may only be useful to self-referencing tables, but
without simple testing I'm having a hard time visualizing it. :)
On Nov 17, 2:16 pm, BrendonKoz <[EMAIL PROTECTED]> wrote:
> counterCache was half-working when I was testing...I only tested (with
> self-referencing tables) the creation of children nodes, not checking
> NEW parent nodes creations...due to how updateAll works within the
> Model::updateCounterCache method, NEW parent nodes (in a self-
> referencing table) will first search for ALL foreign keys that match
> NULL (in essense, getting the total number of parent nodes, including
> itself) and using that value to update the table_count record.
>
> In other words, it doesn't seem to work with self-referencing tables
> (at this time?). For my own solution, I think I'm just going to use
> an afterSave method in my model to do what I need. I believe it'll
> use the same number of queries as the counterCache method was anyway.
>
> On Oct 27, 7:25 pm,BrendonKoz<[EMAIL PROTECTED]> wrote:
>
> > Sorry, I didn't explain my specific situation. In my case, all I
> > wanted to do was check to see which items in my table had children;
> > that was all I wanted to know for my specific case. counterCachewas
> > all I needed, but when I couldn't get it to work (due to my own
> > mistakes) I turned to counterQuery. TreeBehavior was seemingly the
> > only last option I had, but really didn't want to use (as it was huge
> > overkill). I ended up gettingcounterCacheto work before looking too
> > deeply in to TreeBehavior, but I am curious to know if counterQuery is
> > implemented in Cake 1.2 RC3.
>
> > Thanks for the link showing how to do more with counter cache. I like
> > to learn as much as I can in regards to Cake.
>
> > On Oct 27, 5:15 pm, AD7six <[EMAIL PROTECTED]> wrote:
>
> > > On Oct 27, 8:37 pm,BrendonKoz<[EMAIL PROTECTED]> wrote:
>
> > > > OK -CounterCachedoes work on self-joined tables (I had declared my
> > > > association key forcounterCachein the wrong relation). I'm still
> > > > curious about counterQuery, however.
>
> > > >CounterCacheis actually the best solution for my current task at
> > > > hand, but I may like to use counterQuery at some point without the
> > > > extra overhead of using a Tree or custom behavior.
>
> > > If you are using the tree behavior, you really shouldn't need a self
> > > join - I don't understand you're apparent choice between using the
> > > tree behavior and using counterQuery/cache, they are in no way
> > > equivalent or overlap.
>
> > > Here's an example of how to use counter cache to do more than it does
> > > by default:http://bin.cakephp.org/view/156582655
>
> > > hth
>
> > > AD
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CakePHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
