Thanks, Kris, that would have worked too. I forgot of course to mention the most important and that is that I am using Propel 1.3. And in there, there is no longer doSelectRS and I have to change my hooks to doSelectStmt() but this also did not help because doCount*() methods no longer use doSelectStmt() to get the count.
I have updated sfPropel13 plugin to take that into consideration and all is working as expected. Thank you again. Kiril On Wed, Apr 2, 2008 at 11:54 AM, Kris Wallsmith <[EMAIL PROTECTED]> wrote: > > I've encountered similar problems with behaviors in the past (I think > the paranoid behavior, specifically) and was able to resolve them by > adding a require_once to the top of the class file that pulls in its > partner class. > > For example, in Collection.php: > > <?php > require_once dirname(__FILE__).'/CollectionPeer.php'; > class Collection extends BaseCollection ... > > and in CollectionPeer.php: > > <?php > require_once dirname(__FILE__).'/Collection.php'; > class CollectionPeer extends BaseCollectionPeer ... > > Hope that helps, > Kris > > On Apr 2, 6:26 am, "Francois Zaninotto" <[EMAIL PROTECTED] > > project.com> wrote: > > Kiril, > > > > doCount does a doSelectRS, and doSelectRS has a mixin hook. Therefore you > > can hook to doCount as you hook to every selection method - and I don't see > > any use case where you'd want to change the count but not the selection. > > > > As for the loading issue, this is indeed corrected by the AlternativeScema > > plugin in sf1.0, and in the core in 1.1. > > > > Cheers, > > > > François > > > > 2008/4/2, Kiril Angov <[EMAIL PROTECTED]>: > > > > > > > > > > > Hello, > > > > > here are several issues I encountered while trying to work on a Propel > > > behavior. > > > > > 1) Why do we have the mixins only on certain Peer methods (for example > > > we cannot make a behavior on doCount() or any of the count methods). > > > Is there a reason the rest are not supported or it was just overlooked > > > at that time. I am asking because I added the mixins for doCount*() > > > and I can modify successfully use Propel behavior on it. > > > > > 2) This was a little tricky to find but here is what I noticed. When > > > we have behaviors, we usually define them in the model class, at the > > > end of it. And in my situation I have a problem because when I call a > > > static method like CollectionPeer::doSelectJoinCollector($c), the > > > symfony autoloading is loading CollectionPeer.php which in turns calls > > > the sfPropelBehavior::add() but the function was already executed! > > > Which means that the first ever method that I call from CollectionPeer > > > class will not be executed after the Propel behavior is being added > > > but before that. This is some really strange but it seems like the > > > CollectionPeer::doSelectJoinCollector($c) call is executed first > > > before anything in CollectionPeer.php file. > > > > > I hope I explained well the problem but this is causing unexpected > > > behavior when your very first call to the Peer object depends on the > > > Propel behavior to be loaded. So as a solution I moved the > > > sfPropelBehavior::add() calls to the config.php file where I defined > > > the hooks and this makes sure the behavior is loaded before any calls > > > to the model classes but we should either make that clear somewhere or > > > if possible find a solution to this. > > > > > Thanks, > > > Kiril > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
