Запрос не вернет связанный объект $ own_many_many в Silverstripe 3.4
у меня много ArticlePageс, которые могут появиться на многих BlogPageс, но ArticlePage::get()->filter('BlogPage.ID', $parentID) не возвращает ожидаемое ArticlePageс из базы данных.
Я проверил, что страницы опубликованы, и BlogPage_ArticlePages таблица хранит отношения правильно.
BlogPage.php:
class BlogPage extends Page {
...
private static $many_many = array(
'ArticlePages' => 'ArticlePage'
);
...
}
ArticlePage.php:
class ArticlePage extends Page {
...
private static $belongs_many_many = array(
'BlogPages' => 'BlogPage'
);
...
}
Список / запрос:
$parentID = 12;
ArticlePage::get()->filter('BlogPages.ID', $parentID);
Решение
Это сработало для меня:
$parentID = 12;
$query = ArticlePage::get()->innerJoin(
$table = '(SELECT "BlogPage_ArticlePages"."ArticlePageID" FROM "BlogPage_ArticlePages" INNER JOIN "BlogPage" ON "BlogPage_ArticlePages"."BlogPageID" = "BlogPage"."ID" WHERE "BlogPage"."ID" = ?)',
$onClause = '"BlogPage"."ArticlePageID" = "SiteTree"."ID" ',
$alias = "BlogPage",
$order = 20,
$parameters = array($parentID)
);
BlogPage а также ArticlePage оба являются потомками SiteTreeпоэтому требуется более явное выражение, чтобы избежать конфликтов имен в результирующем запросе.
Разработчик Silverstripe TractorCow сообщил мне, что способ отображения запросов Silverstripe 3 имеет некоторые ограничения, и дал мне обходной путь, но предположил, что это может быть улучшено, если время позволит.
объяснение:
Когда Silverstripe 3 формирует запрос SQL для потомков SiteTree, он использует SiteTree стол (и SiteTree «как псевдоним»). Когда ->filter('BlogPage.ID') добавлен в запрос, Silverstripe использует SiteTree как псевдоним (снова). Это создало конфликт ссылок, и ни одна запись не была найдена.
->innerJoin() выше запросы соответствующие BlogPage данные и псевдонимы как BlogPage вместо SiteTree, $table выражение в ( ) является «циклической» ссылкой, которая предоставляет то, что мы можем использовать для псевдонима более подходящим образом.
Другие решения
Других решений пока нет …