Thanks.
That looks a lot like what I have apart from creating the "dummy
hasMany" to use as a template for the queries. I have left that out as
it generates an extra query and used App::import() instead.
Your code is very helpful none the less. It contains a few more checks
and tricks than my current version. Thanks again!
On Jan 15, 1:31 pm, grigri <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
