> 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
-~----------~----~----~----~------~----~------~--~---
