Erm sorry, that last loop should be:

  foreach ($results as $i => $row) {
    $query['conditions'] = array('Person.' . $row['Rule']['key'] =>
$row['Rule']['operator'] . $row['Rule']['value']);
    $people = $this->Person->find('all', $query);
    $results[$i]['Person'] = array();
    foreach ($people as $subRow) {
      $person = $subRow['Person'];
      unset($subRow['Person']);
      foreach ($subRow as $key => $value) {
        $person[$key] = $value;
      }
      $results[$i]['Person'][] = $person;
    }
  }

On Jan 15, 12:28 pm, grigri <[EMAIL PROTECTED]> wrote:
> > So, there is no public callback wedged between the query on "this"
> > model and the queries for the associated models? Too bad.
>
> Well, non-join associations (hasMany / HABTM) are effectively separate
> queries after the main query, so doing them in afterFind() wouldn't be
> a problem.
>
> [warning: These are just ideas; nothing is tested]
>
> Assuming rules table contains fields : key, operator, value [eg: key
> => 'shoe_size', 'operator' => '>', 'value' => 43]
>
> Lots of SQL calls method:
>
> class Rule extends AppModel {
>
> /* Add a dummy hasMany. This will ensure that :
>    -> this model has access to the Person model
>    -> if a Person key is set in the results array then the recursive
> setting is
>        high enough to request the Person associations
>    -> You can define fields, order, whatever in the normal way
> */
> var $hasMany = array(
>   'Person' => array(
>     /* leave these as-is */
>     'foreignKey' => 'id', 'conditions' => '1=0',
>     /* set these appropriately */
>     'fields' => array('id', 'email', 'shoe_size'),
>     'order' => 'Person.name ASC',
>     /* set this to always use the given recursive number, set to null
> for default */
>     'recursive' => null
>   );
> );
>
> function afterFind($results) {
>   if (!isset($results[0]['Person'])) {
>     // Don't want the association, or zero results. Either way, abort
>     return $results;
>   }
>   $query = array(
>     'conditions' => array(),
>     'recursive' => is_null($this->hasMany['Person']['recursive']) ?
> ($this->recursive - 1) : $this->hasMany['Person']['recursive'],
>     'fields' => $this->hasMany['Person']['fields'],
>     'limit' => $this->hasMany['Person']['limit'],
>     'order' => $this->hasMany['Person']['order'],
>   );
>   foreach ($results as $i => $row) {
>     $query['conditions'] = array('Person.' . $row['Rule']['key'] =>
> $row['Rule']['operator'] . $row['Rule']['value']);
>     $people = $this->Person->find('all', $query);
>     foreach ($people as $subRow) {
>       $person = $subRow['Person'];
>       unset($subRow['Person']);
>       foreach ($subRow as $key => $value) {
>         $person[$key] = $value;
>       }
>       $results[$i]['Person'] = $person;
>     }
>   }
>   return $results;
>
> }
> }
>
> Actually, that was longer than I thought it was going to be. I'll
> leave the 'one huge SQL call' method for later, and the hybrid method
> for even later.
>
> On Jan 15, 10:32 am, "[EMAIL PROTECTED]"
>
> <[EMAIL PROTECTED]> wrote:
> > So, there is no public callback wedged between the query on "this"
> > model and the queries for the associated models? Too bad.
>
> > I guess I will have to drop the idea of using associations and instead
> > load the data in afterFind() or possible even in the controller.
>
> > Some more details:
> > I am developing with the intent of running the application on a
> > dedicated server (or number thereof) with php5 and mysql5 (pretty
> > standard LAMP setup).
>
> > What I am doing is creating a filter (well... trying to anyway) that
> > will filter a table of people (contacts) based on data stored in the
> > contacts table. It would make life easy for views and controllers if I
> > could just call for a filter called "people with big feet" and loading
> > this filter also loads relevant contacts (WHERE Contact.shoe_size > 43
> > or something). Filter-rules can be edited until you get the ultimate
> > selection of people... this will naturally be used for marketing and
> > not cancer-research or anything noble like that.
>
> > Building this dynamic "relationship" without hasMany is not big
> > problem. It would just be super-über-cool to do it that way. That is
> > why I am spending precious time trying to bend Cake to my will :)
>
> > If you, or anyone else, has any further tips please feel free...
> > If not, thanks to grigri for your info so far. it was helpful.
>
> > On Jan 15, 11:06 am, grigri <[EMAIL PROTECTED]> wrote:
>
> > > 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 [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
-~----------~----~----~----~------~----~------~--~---

Reply via email to