Yeah, the foreignKey => false bit is quite recent. For some reason support for beforeFind on associated models is not being planned, as far as I know.
This is a really big issue for code like the TranslationBehavior which can't translate its associated models (do a search on this group and you'll see). a quote from gwoo: > we have discussed this internally, and have determined that for now > running beforeFind on associations will cause problems with overhead and > conflicts. > Most certainly this is not a bug. It is a known limitation of the beforeFind > callback. and from nate: > The overhead required for enabling this would not be worth it's limited > usefulness. Create a behavior. Personally I'd like to see this issue resolved, but I understand that it could be tricky to code efficiently and there are more important things to do to the cake core. I must say though, your requirements do look quite difficult. Obviously it depends enormously on the amount of rules and associated data you will have stored (hundreds? thousands? millions?). The naive implementation (post-process record by record using afterFind) would generate a lot of SQL calls and would slow your application down quite a bit, although judicious use of caching could improve this. I'm sure it's possible to come up with a better idea though, can you give some more detailed information on your table structure? And what database system + version you're using, in case we need anything specific. On Jan 15, 9:35 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > The reason I was using finderQuery for these early tests was that > 'foreignKey'=>false gave me errors. Could be Cake 1.2 beta problem > with that one possibly. > > My biggest problem though is finding a callback to do the setting of > the conditions/finderQuery. > Rule::beforeFind() - I don't have the data from the rules table. > Rule::afterFind() - I have the data but I also already have the > associated data. > > The sequence I a getting from debug calls is: > Rule::beforeFind > Contact::afterFind > Rule::afterFind > (that's right. no beforeFind from the associated model even using > normal hasMany without finderQuery) > > On Jan 15, 10:22 am, grigri <[EMAIL PROTECTED]> wrote: > > > You can use just the 'conditions' key if you set 'foreignKey' to > > false. Using finderQuery doesn't activate all the automagic binding > > and whatnot, so this is probably a better idea. > > >https://trac.cakephp.org/ticket/3323https://trac.cakephp.org/changese... > > > On Jan 15, 8:56 am, "[EMAIL PROTECTED]" > > > <[EMAIL PROTECTED]> wrote: > > > And of-course when I wrote conditions I was really talking about > > > "finderQuery". Sorry. > > > > On Jan 15, 9:32 am, "[EMAIL PROTECTED]" > > > > <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I have a question that hasn't been on the table much. It is a bit of > > > > an oddball scenario. > > > > > Can I use dynamic data from the model's table in the "conditions" for > > > > an association? > > > > > I have a model that stores filter-rules. e.g. "email is from > > > > cakephp.org" or "age is more than 40" things of this nature. These are > > > > representative of an appropriate where-clause that finds the > > > > corresponding items in another model filled with "people". > > > > > It all works when I "manually" search out the people. What would be > > > > cool is if I could very cleanly use Cake's associations in some way. > > > > > I can use the hasMany property caled "conditions" to statically put my > > > > filter-rule there for the whole class. But I would like to be able to > > > > use the table-data in the condition. Each record using it's own "rule- > > > > clause" Is this possible? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
