Помогите составить запрос &where в pdoResources
Добрый день, помогите мне пожалуйста составить правильный запрос where, вот мой код
[[!pdoPage?
&element=`pdoResources`
&tpl=`zayavka_block`
&parents=`1`
&tplPageActive=`@INLINE<li class="current"><a href="[[+href]]">[[+pageNo]]</a></li>`
&cache=`1`
&cacheTime=`1800`
&includeTVs=`metro,img,price_do,price_ot,street,area,price,object_id,kavdrat_ot,kavdrat_do,okrug`
&hideContainers=`1`
&where=`{
"metro:LIKE:OR":[ "%[[*svod_metro]]%" ],
"price:IN":[ [[*svod_price]] ],
"okrug:LIKE:OR":[ "%[[*svod_okrug]]%" ]
}`
&maxLimit=`9`
&showLog=`1`
]]
у меня есть три поля, необходимо сделать так чтобы каждый из параметров принимал много значений через запятую, но много значений нормально принимает только price, если же указать несколько станций метро через запятую таким же способом то все ломается Комментарии: 27
несколько станций метро через запятую таким же способом то все ломаетсяПотому что станции метро — текст и через запятую они должны быть вместе с ковычками.
Вместо
текст, текст, текст
должно быть"текст","текст","текст"
Числа в ковычки помещать не нужно, поэтому цена работает. Если включить showLog=`1`, то ты увидишь ошибку выполнения SQL запроса.
так ведь в ковычках же [ "%[[*svod_metro]]%" ], ошибка есть
0.0013440: Could not process query, error #1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '`TVokrug`.`value` `modResource`.`LIKE` OR 'Array' AND `modResource`.`parent` IN ' at line 1
0.0259030: Total time
я уже сутки бьюсь, по всякому пытался, с ковычками без ковычек, со знаком % и без него, пробовал делать через IN, не выходит =(
Угу, в таких ковычках выходит
Разницу видишь или показать?
"текст,текст,текст"
Разницу видишь или показать?
Вижу, так как ты говоришь тоже пробовал. У меня вообще правильно сделано? Это самое метро так и надо через LIKE или через IN?
Ну ты в SQL смотри, что получается и думай. «metro:LIKE:OR» — такого вообще нет, это неправильно.
на сайте шопкипера подсмотрел, там пишут работает
1. Там &tvFilters, а не where.
2. СМОТРИ SQL, КОТОРЫЙ ПОЛУЧАЕТСЯ!!!!
Все эти параметры и сниппеты нужны только для одного — сгенерировать sql запрос. Если он выходит неправильным, значит нужно генерировать как-то иначе.
Ты сейчас влепую что-то придумываешь, когда можно просто посмотреть в лог и подкорректировать параметры для правильного составления запроса.
2. СМОТРИ SQL, КОТОРЫЙ ПОЛУЧАЕТСЯ!!!!
Все эти параметры и сниппеты нужны только для одного — сгенерировать sql запрос. Если он выходит неправильным, значит нужно генерировать как-то иначе.
Ты сейчас влепую что-то придумываешь, когда можно просто посмотреть в лог и подкорректировать параметры для правильного составления запроса.
спасибо, разобрался
получается если мне нужно искать значение мжде например значение одного ТВ параметра и значением другого надо использовать BETWEEN?
BETWEEN всегда ищет по одному полю и двум значениям. Типа
Сниппеты и готовые решения — это конечно прекрасно, но основы SQL тоже нужно знать.
WHERE date BETWEEN '2014-01-01' AND '2014-05-01'
Сниппеты и готовые решения — это конечно прекрасно, но основы SQL тоже нужно знать.
буду, обещаю, спасибо
Чтоб не плодить одинаковых тем, воспользовался поиском, решения не нашел.
Пытаюсь сделать выборку по url.
Делаю так:
В результат он попросту игнорирует этот параметр.
Что не так?
Пытаюсь сделать выборку по url.
Делаю так:
&where=`{"url:LIKE":"%[[UrlPath]]%"}`
где [[UrlPath]] == url path строкаВ результат он попросту игнорирует этот параметр.
Что не так?
Если это сниппет, то он у тебя вызывается кэшируемый. [[!UrlPath]] нужно.
И по хорошему бы код из сниппета показать.
Ну я писал что это всего лишь строка ссылки.
$url = $_SERVER['REQUEST_URI'];
$url = ltrim($url, '/');
return $url;
Дак я не понял, ты убрал нет кэшироване? Помогло?
Я убрал даже сам вызов, дело не в сниппете, а в запросе.
&where=`{"url:LIKE":"%stude%"}`
— ищем часть слова student
Не url, а uri!
=) кошмар!
Если прописать
&sortby=`url`
вообще ничего не выведет, м.б. нельзя по url искать и сортировать?
Тебе Василий ответил выше.
Да, опечатка, но это не помогло =)
Уже и alias пытался найти, ему вообще все равно что я ему пишу в where.
Вызов pdoResources:
Уже и alias пытался найти, ему вообще все равно что я ему пишу в where.
Вызов pdoResources:
[[pdoResources? &select=`uri,id,pagetitle,introtext,publishedon,createdby` &limit=`3` &hideContainers=`1` &parents=`1` &sortby=`uri` &where=`{"uri:LIKE":"%stude%"}`]]
Ты все время вызываешь сниппеты кэшируемые. Может в этом проблема?
Пробовал и без, результат один.
ps Василий предусмотрел параметр showLog=1, для того чтобы посмотреть запросы. Ищи в них ошибки, если проблема не в кэше.
Ошибок нет. Все это странно м.б. синтаксис не верный? и он игнорирует параметр?
Вывод данных не верный, выводятся ресурсы где stude даже и нет в uri, но сортировка по uri работает.
<pre class="pdoResourcesLog">0.0000961: pdoTools loaded
0.0000200: xPDO query object created
0.0001481: Added selection of <b>modResource</b>: <small>SQL_CALC_FOUND_ROWS `uri`, `id`, `pagetitle`, `introtext`, `publishedon`, `createdby`</small>
0.0018809: Processed additional conditions
0.0022321: Added where condition: <b>uri:LIKE=%stude%, modResource.parent:IN(1,43,5,365,7,398,9,10,328,338,344,686,687,341,688,319,689,655,334,733,337,734,1057,331,706,709,735,736,882,982,737,738,635,918,939,712,347,716,863,616,739,740,834,447,448,725,1025,719,325,312,322,315,871,898,477,478,479,263,787,654,316,872,1021,1022,1024,350,353,356,359,362,723,864,866,726,973,979,69,70,71,72,1001,582,1003,624,1004,879,892,912,923,940,966,1078,1082,1087,1091,1094,1095,368,371,374,377,380,383,386,389,392,395,408,482,499,414,641,643,650,771,851,934,843,874,446,480,642,651,929,949,952,783,784,911,913,1002,1032,1033,1063,1068,611,779,877,919,920,921,922,925,926,927,928,963,1008,1012,1018,1034,1042,1043,1046,1047,773,839,840,841,876,907,941,782,838,1041,1066,1067,842,847,498,481,492,856,935,945,947,962,832,837,539,631,777,788,836,846,870,883,887,890,942,1035,404,406,674,760,828,857,1090,415,418,421,858,1049,1051,1052,860,861,1054,1050,1055,424,427,430,433,632,629,903,904,905,776,980,981,638,639,640,897,1013,1014,1016,1000), modResource.published=1, modResource.deleted=0, modResource.isfolder=0</b>
0.0000751: Sorted by <b>modResource.uri</b>, <b>DESC</b>
0.0000019: Limited to <b>3</b>, offset <b>0</b>
0.0004411: SQL prepared <small>"SELECT SQL_CALC_FOUND_ROWS `modResource`.`uri`, `modResource`.`id`, `modResource`.`pagetitle`, `modResource`.`introtext`, `modResource`.`publishedon`, `modResource`.`createdby` FROM `modx_site_content` AS `modResource` WHERE ( `modResource`.`uri` LIKE '%stude%' AND `modResource`.`parent` IN (1,43,5,365,7,398,9,10,328,338,344,686,687,341,688,319,689,655,334,733,337,734,1057,331,706,709,735,736,882,982,737,738,635,918,939,712,347,716,863,616,739,740,834,447,448,725,1025,719,325,312,322,315,871,898,477,478,479,263,787,654,316,872,1021,1022,1024,350,353,356,359,362,723,864,866,726,973,979,69,70,71,72,1001,582,1003,624,1004,879,892,912,923,940,966,1078,1082,1087,1091,1094,1095,368,371,374,377,380,383,386,389,392,395,408,482,499,414,641,643,650,771,851,934,843,874,446,480,642,651,929,949,952,783,784,911,913,1002,1032,1033,1063,1068,611,779,877,919,920,921,922,925,926,927,928,963,1008,1012,1018,1034,1042,1043,1046,1047,773,839,840,841,876,907,941,782,838,1041,1066,1067,842,847,498,481,492,856,935,945,947,962,832,837,539,631,777,788,836,846,870,883,887,890,942,1035,404,406,674,760,828,857,1090,415,418,421,858,1049,1051,1052,860,861,1054,1050,1055,424,427,430,433,632,629,903,904,905,776,980,981,638,639,640,897,1013,1014,1016,1000) AND `modResource`.`published` = 1 AND `modResource`.`deleted` = 0 AND `modResource`.`isfolder` = 0 ) ORDER BY modResource.uri DESC LIMIT 3 "</small>
0.0085208: SQL executed
0.0003641: Total rows: <b>0</b>
0.0000291: Rows fetched
0.0000019: Returning processed chunks
0.0120859: <b>Total time</b>
7 864 320: <b>Memory usage</b>
</pre>
Вывод данных не верный, выводятся ресурсы где stude даже и нет в uri, но сортировка по uri работает.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.