CakePHP 订单查询结果超过 1 级
我使用 Containable 行为来获取评论列表(belongsTo Post,属于 Question;Question hasMany Post,Post hasMany Comments;所有这些都属于 Users)。
$data = $this->Question->find ( 'first',
array ('contain' =>
array ('User',
'Post' => array ('User', /* 'order' => 'User.created DESC'*/ )
)
)
);
当我注释掉上面评论中的部分时,它起作用了。我想这是可以预料的,但我想要的是找到的所有帖子都应该按照它们所属的“用户”的“创建”字段的顺序排序。如何在 CakePHP 中完成这种更深层次的排序?我总是收到“警告(512):SQL错误:1054:'order子句'中的未知列'User.created'”
感谢您的帮助!
I'm using the Containable behavior to get a list of Comments (belongsTo Post, which belongs to Question; Question hasMany Post, and Post hasMany Comments; all of these belong to Users).
$data = $this->Question->find ( 'first',
array ('contain' =>
array ('User',
'Post' => array ('User', /* 'order' => 'User.created DESC'*/ )
)
)
);
It works, when I comment out the section in comments above. I suppose this is to be expected, but what I want is all of the Posts that are found, should be sorted in order of the 'created' field of the 'User' they belong to. How do I accomplish this deeper level sorting in CakePHP? I always get, "Warning (512): SQL Error: 1054: Unknown column 'User.created' in 'order clause'"
Thanks for your help!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
此外,您可能尝试通过不使用联接的查找调用对相关表进行分组。
将调试级别设置为大于 1,以便您可以查看查询日志并确保 Cake 不会执行两次查询来获取您的数据。如果是这种情况,那么第一个查询实际上并未引用第二个表。
如果您想在这些情况下手动强制加入,可以使用 Nate 在以下链接中概述的临时加入方法。
http://面包店。 cakephp.org/articles/view/quick-tip-doing-ad-hoc-joins-in-model-find
Also, you might be trying to group on a related table from a find call that doesn't use joins.
Set your debug level to something greater than 1 so you can see the query log and make sure that Cake isn't doing two queries to fetch your data. If that is the case then the first query is not actually referencing the second table.
If you want to manually force a join in these situations you can use the Ad-Hoc joins method outlined by Nate at the following link.
http://bakery.cakephp.org/articles/view/quick-tip-doing-ad-hoc-joins-in-model-find
我找到了两种方法来解决这个问题。
第一种是直接在模型中定义第二级关联。
现在您可以在任何地方访问这些数据。
它应该看起来像这样......
这种方法的问题是它可能使一般查询比他们需要的更复杂。
因此,您还可以将第二级查询直接添加到查找或分页语句中,如下所示:(注意:我发现由于某种原因,您不能在第二级连接中使用 $belongsTo 关联,并且如果它们例如,如果 $belongsTo 中已经定义了 'Foo',则需要创建一个重复的 'Foo1' 才能使关联正常工作,如下例所示。)
我希望这足够清楚地理解并且它可以帮助某人。
I have found two ways to get around this.
The first is to define the second level associacion directly in the model.
Now you will have access to this data everywhere.
It should look something like this.....
The problem with this method is that it could make general queries more complex than they need be.
You can thus also add the second level queries directly into te find or paginate statement as follows: (Note: I found that for some reason you can't use the $belongsTo associations in the second level joins and will need to redefine them if they are already defined. eg if 'Foo' is already defined in $belongsTo, you need to create a duplicate 'Foo1' to make the association work, like the example below.)
I hope this is clear enough to understand and that it helps someone.
检查你的递归值。如果限制太多,它将忽略可包含的链接,IIRC。我记得我曾多次遇到过这个问题。我尝试包含多个模型,但我的
recursive
选项设置为0
并且不会提取任何内容。对于您的示例,我认为值1
(默认值)就足够了,但也许您已在某处将其显式设置为0
?Check your recursive value. If it's too limiting, it will ignore the containable links, IIRC. I remember bumping into this a few times. I'd try containing multiple models, but my
recursive
option was set to0
and nothing would get pulled. For your example, I'd think that a value of1
(the default) would suffice, but maybe you've explicitly set it to0
somewhere?您可以在调用 find() 之前添加以下内容:
You can add before your call to find() the following:
是的,我无法弄清楚如何根据相关/关联模型进行排序,因此最终使用了
Set::sort()
方法。查看这篇文章一个很好的解释。...是的,它可能应该是一个
Category->find()
但不幸的是原始开发人员没有那样编码,而且我不想重新处理视图。Yeah, I couldn't work out how to sort based on the related/associated model, so ended up using the
Set::sort()
method. Checkout this article for a good explanation....And yes, it should probably be a
Category->find()
but unfortunately the original developer didn't code it that way, and I didn't wanna rework the views.