(底部更新)
我试图在我的表中获取名为" VersionHistory"的最新条目,并且由于ID设置为自动递增,我试图获得最大ID。试图远离按降序对整个表进行排序并采取顶部,因为我希望在表增长时最小化此查询所需的计算,并且此表可能会非常快速地进行。
class VersionHistoryQuery extends BaseVersionHistoryQuery {
public function getLatestVersion() {
return $this
->withColumn('MAX(version_history.id)')
->limit(1);
}
}
我在我的VersionHistory构造函数中调用函数,如下所示:
class VersionHistory extends BaseVersionHistory {
public function __construct($backupPath = "") {
$lastVersion = VersionHistoryQuery::create()
->getLatestVersion()
->find();
$lastVersion->setBackupPath("backup/" . $backupPath);
$lastVersion->save();
parent::setImportedAt(date("Y-m-d H:i:s"));
}
}
输出"允许的内存大小耗尽" php中的错误。知道为什么吗?在VersionHistory构造函数中注释掉查询可以修复错误,因此它在查询中的某个位置。我尝试按照此处的说明设置自定义查询:http://propelorm.org/documentation/03-basic-crud.html#using-custom-sql。但我无法让它发挥作用。运行:
SELECT * FROM version_history WHERE id = (SELECT MAX(id) FROM version_history)
从MySQL工作台可以很好地工作。
关于我做错了什么的想法?
将代码更新为:
public function getLatestVersion() {
return $this
->orderById('desc')
->findOne();
}
仍然得到相同的内存分配错误。
将代码更新为:
$lastVersion = VersionHistoryQuery::create()
->orderById('desc')
->findOne();
删除自定义功能,打开推进调试模式,输出该查询运行:
[2015-10-11 17:26:54] shop_reporting_db.INFO: SELECT `version_history`.`id`, `version_history`.`imported_at`, `version_history`.`backup_path` FROM `version_history` ORDER BY `version_history`.`id` DESC LIMIT 1 [] []
仍然遇到内存溢出。
答案 0 :(得分:1)
多数民众赞成:
SELECT * FROM version_history ORDER BY id DESC LIMIT 1;
答案 1 :(得分:1)
从文档中,withColumn执行以下操作:
Propel将'添加到'列的查询的SELECT子句,和 使用withColumn()调用的第二个参数作为列别名。
因此,看起来您实际上是在查询表中的每一行,并且每一行都在查询最大ID。
我对推进一无所知(除了我刚刚用Google搜索的内容),但看起来您需要一种不同的方式来指定您的位置条件。
答案 2 :(得分:0)
您的原始SQL和您的Propel查询不同/不相同。
在推进查询中只添加了一列,而您的原始SQL实际上有两个查询,其中一个是对另一个的子查询。
所以你需要在Propel中做同等的事情:
$lastVersionID = VersionHistoryQuery::create()
->withColumn('MAX(id)', 'LastVersionID')
->select('LastVersionID')
->findOne();
$lastVersion = VersionHistoryQuery::create()
->filterByVersionHistory($lastVersionID)
->find();
注意->select('LatestVersionID')
,因为您只需要标量值而不是整个对象,以及使用withColumn()