Каждое сообщение имеет значение широты/долготы, прикрепленное к нему через postmeta. Я пытаюсь захватить все сообщения в пределах ограничивающего значения широты/долготы. Вот get_posts
запрос:
$posts = get_posts(array(
'posts_per_page' => 100,
'post_type' => 'place',
'post_status' => 'publish',
'meta_query' => array(
array(
'key' => 'places_lat',
'value' => array($lat_min, $lat_max),
'compare' => 'BETWEEN',
//'type' => 'DECIMAL',
),
array(
'key' => 'places_lng',
'value' => array($lng_min, $lng_max),
'compare' => 'BETWEEN',
//'type' => 'DECIMAL',
),
),
));
Поскольку значения postmeta хранятся в виде строк, я решил, что должен приводить к DECIMAL
, но, похоже, это просто обрезает десятичное значение из строки из-за отсутствия DECIMAL
аргументов/параметров точности.
Я заметил, что запрос обрабатывает числа с плавающей запятой в value
массиве как строки, что также может быть еще одной точкой отказа. Выполнение скомпилированного запроса без кавычек вокруг каждого плавающего значения работает должным образом.
Я буду использовать get_permalink()
в каждом посте. Я могу запустить собственный запрос за пределами get_posts
(через $wpdb->get_results()
), чтобы правильно захватить сообщения в ограничивающей рамке, а затем перебрать сообщения и get_permalink
, но в конечном итоге это приведет к запуску дополнительного запроса к базе данных для каждого сообщения для создания постоянной ссылки — не идеальное решение!
Есть идеи?
Побочное примечание: я бы не стал делать запрос местоположения для
postmeta
таблицы, таким образом будет сложно извлечь выгоду из индексов. Однажды я написал пример, который копирует геоданные публикации в отдельную таблицу с эффективным индексом и выполняет геозапросы к этой таблице.Вы даже можете использовать более конкретный фильтр:
get_meta_sql
, так как часть запроса таксономии создается в_get_meta_sql()
. Это также не зависит отsuppress_filters
, поэтому вам не нужно его отключать.Спасибо, Рарст, и еще раз спасибо, Ян! Я думаю, что лучшим вариантом в этом случае будет перемещение значений широты/долготы в отдельную таблицу для лучшей индексации.
попробовал оба решения, и похоже, что он сравнивает их как строки с одинарными кавычками (wp 3.1.1), есть идеи по этому поводу? хотя попытка сырого sql сработала.
@Amit Ничего я не могу здесь догадаться… Обычно это долгая отладочная путаница с кодом, связанным с запросами.
Вы можете отфильтровать сгенерированный SQL и добавить необходимые параметры точности.
Включите фильтры для
get_posts()
, добавив в запрос следующее:А также:
Обновлять
По предложению Яна:
Начиная с версии 3.8 ( см. track ) точность может быть добавлена к типу приведения следующим образом: