Thank you for the replies. I just started using the AlternativeScema plugin but did not define the behaviors in the schema so if that solutions work, it would be perfect.
About the doCount*() methods. I definitely had the doSelectRS() in my behavior hooks but until I added a separate hook for doCountJoin(), it never took into account the behavior. I was working late last night so I might have missed something so I will recheck for the doCount*() and definitely move the behaviors to the schema. Thank you again, Kiril On Wed, Apr 2, 2008 at 9:26 AM, Francois Zaninotto <[EMAIL PROTECTED]> 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 -~----------~----~----~----~------~----~------~--~---
