вот она магия 100 уровня_)

ахаха, меня сегодня прёт не перлы ))

$query->addFilter(null, array( 'LOGIC' => 'OR', '=STATUS' => \CTasks::STATE_NEW, array( 'LOGIC' => 'OR', '=STATUS' => \CTasks::STATE_PENDING, ) ));

'=STATUS' => [\CTasks::STATE_NEW, \CTasks::STATE_PENDING]

нет. тогда IN включится

а IN плохо работает с индексами

http://stackoverflow.com/questions/586381/mysql-not-using-indexes-with-where-in-clause

а поставить условие статус меньше 3 - не подойдет?

$query->addFilter(null, array( 'LOGIC' => 'OR', '=STATUS' => \CTasks::STATE_NEW, array( '=STATUS' => \CTasks::STATE_PENDING, ) ));

а я про цифры ничего не знаю

ок. тогда только копать класс фильтра

$query->addFilter(null, array( 'LOGIC' => 'OR', array( '=STATUS' => \CTasks::STATE_NEW, ), array( '=STATUS' => \CTasks::STATE_PENDING, ) ));

вот так правильней будет

Добрый день! Подскажите может кто сталкивался, при применении купона на скидку, она слетает при изменении статуса заказа. В чем могут быть причины?

вообще не должно так быть, так что где-то наверное есть код, который к примеру заново собирает заказ и не применяет купон и т.д. поищи обработчики событий и посмотри кто-что туда напихал

Ща маман звонила, денег срочно 5 тыс надо. отец в аварию попал. Звоню ей, спрашиваю а чо так мало? та меня спросони спрашивает чего мало?

отец тоже с ночной. видимо с кровати упал. срочно нужна помосчь

куда деньги переводить?

у меня маму разводили как то, звонят моим голосом, мам я в аварию попал, помоги, надо заплатить. Она спросила, Олег, ты чтоли? Да мам, это я. Странно, как ты из коляски можешь мне звонить? бросили трубу чот.

Маам. моя коляска попала в ДТП. Более старший мальчик хочет разойтись полюбовно. Купи килограмм конфет и принеси во двор пожалуйста.

ребят

по мускулю можете подсказать?

выборки в JOIN ON и в WHERE если есть возможность или там или там писать, есть разница ?

например

дополнительно проверяется TYPE=A из джойнутой таблицы.

есть разница, вставить в джоин он этот кондишн или в where

в джоин параметри склейки, в where параметры фильтрации, что куда вставить хотите?

ну смотри, мож я не верно мыслю...

для меня джоин это некая виртуальная выборка по кондишину из ОН а потом уже работа с этой виртуальной выборкой в основном запросе. не? потому и хотел отсеять в этом подзапросе лишнее и работать уже только с нужными данными

нет, на пальцах это так, есть таблица А и B, если A сжоинить с B получится табличка C с колонками из A и B и вот тут ты делаешь where C.TYPE = 'A'

в ON ты задаешь сравнение как сопоставить строки из одной таблицы со второй таблицей

а, тоесть он не ускоряет

джоин и скорость штуки не сопоставимые в принципе :)

чтоб ускорить надо отказатся от джоинов вообще))

и как ты тогда предлагаешь работать с данными хранящимися в другой таблице? )))

простыми запросами, конечно какой то простой джоин на небольших выборках особо не замедлит, но если ты задумался об ускорении, значит там не простой джоин A+B, а что то сложнее и боллее объемное (по выбору данных). Проще простыми запросами по индексам работь, то есть вместо одного запроса с 5 джоинами, сделать 5 простых запросов по индексным колонкам

а, ну это я знаю )

ну вот)) нет никакой магии, все на самом деле оч просто))

https://www.youtube.com/watch?v=2B4rOAl_Rpc&feature=youtu.be

https://www.youtube.com/watch?v=nuWh_Q4vlIc

вообще не должно так быть, так что где-то наверное есть код, который к примеру заново собирает заказ и не применяет купон и т.д. поищи обработчики событий и посмотри кто-что туда напихал

Подчеркнулажмте а где обрабатываются купоны? В order.php ?

*подскажите пожалуйста

подчеркнула, жмите ))))

у меня истерика

)))))

Даже боюсь представить откуда в т9 такая комбинация))))

Даже боюсь представить откуда в т9 такая комбинация))))

поставьте себе PC клиент и не мучайтесь с т9))

Да я на работе) тут залочен доступ с пк

в телеграм? в сеть? или просто нет прав админских? Для последнего есть portable версия

Для первого ест возможность настроить прокси

ну а если нет сети, то ...ммм печательно, гуглить решения с трубки наверное не оч производительно получается))

Нет, прокся не дает в телеграм зайти

да и обычно спросить тут вместо ТП сокращает срок разработки проекта))

Гуглю с компа

Нет, прокся не дает в телеграм зайти

как это не дает?)) прокся такая видимо, берете виртуалочку за 99р, настраиваете там nginx..... ?

опера бесплатно впн предоставляет

а потом https://web.telegram.org/#/login

http://joxi.ru/zAND7Y3flpXavm ?

с браузера через бровсерсек можно

даже росчегототамтрах не мешается

Оперу прокся не поддерживает)

Не суть

Оперу прокся не поддерживает)

как у вас все сложно :) Наверное вы работаете в строительной сфере?)))

+

Вопрос по делу. Есть обработчик сохраняющий примененные купоны и проверяющий актуальность товара в корзине, где искать сего зверя?

При изменении статуса заказа

в событиях?

$ grep . "OnSaleStatusOrder" Можно в эту сторону копать попробовать

ERROR: S client not available

только с флагами пошаманить

Добрый день. В стандартном catalog.section можно задать три типа сортировки? Мне нужно чтобы элементы сортировались по наличию (свойство типа список, не используются склады), популярности и индексу сортировки. Или же без кастомизации компонента можно только два типа сортировки задать и на этом все?

Добрый день. В стандартном catalog.section можно задать три типа сортировки? Мне нужно чтобы элементы сортировались по наличию (свойство типа список, не используются склады), популярности и индексу сортировки. Или же без кастомизации компонента можно только два типа сортировки задать и на этом все?

Нужно свойсто типа число, в нем при изменении товара сделать отметку 0 или 1 (нет или есть) и сортировать по нему

сортировать именно по остаткам не выйдет через API т.к. там будет сперва товаров кортых больше всего в базе

сделайте 2 компонента подряд)) первый показывает только популярные > 0 и доступные остальное во второй

ну это если не хотите свой писать)) как то так пошло, что секшены я давно сам пишу

сделайте 2 компонента подряд)) первый показывает только популярные > 0 и доступные остальное во второй

Пробежала такая мысль) но подгрузка товаров на ajax-e и то, чего нет в наличии должно появиться в самом конце, а тут они у меня сразу будут, можно конечно еще как нибудь извернуться, но не оправданно, как мне кажется)

ну сделайте 2 компонента и разделите по наличию

те что в наличие в первом, те что нет во втором. Ajax или нет роли не играет если то что вы получаете по аяксу идентично тому, что вы получите по урлу

а нет

туплю))

в 2 не получится))

пишите свой)) в выборке с инфоблоков нет ничего такого нереального, там 2 десятка строк кода получится (вместе с кэшем)

джоин и скорость штуки не сопоставимые в принципе :)

лол

вполне так сопоставимые..

пишите свой)) в выборке с инфоблоков нет ничего такого нереального, там 2 десятка строк кода получится (вместе с кэшем)

понял, спасибо)

вполне так сопоставимые..

пока выборка влазит в буфер оперативки на запросы в принципе можно как то не запариваться

да и в принципе все зависит от ситуации))

ну меня просто несколько поразила однозначность утверждения от кейса зависит, прям очень-очень когда оказывается что логика джоин прям в коде получается мозговыносная а парсер sql у mysql не такой уж и быстрый (да, такое тоже бывает) то тогда join вполне может быть синонимом - оптимизации конечного времени выполнения

парсер можно отключить)))

всегда стоит сначала о логике подумать, о неудобных данных и не забыть заглянуть в explain

точнее не парсер а оптимизатор

а можно просто не обмениваться этими данными ;)

не, речь о парсере при большом кол-ве простых выборок, которые вполне влезают в буфер - накладки парсера могут чувствоваться

поправка - не в буфер, а в ключи

Я не говорю что джоины зло, я говорю что это в большинстве кейсов проблема при масштабировании, ака оптимизации, акак хайлоад на БД

когда ваша БД начнет тухнуть, вам придется взять вторую и разложить табличци по разным серверам, а кейсов с джоинами 2 серверов пока как то не встречал

Блин, скачал голую коробку битрикс

Та же тема, при оформлении заказа слетает примененный купон

ОоО

если цельную бд придется резать на таблицы в разных бд, изза проблем вставки данных - да, будет проблема если цельная бд не справляется с чтением - слейв все равно будет лучшим вариантом с первой ситуацией я чесгря не сталкивался в реале, только в умных книжках пишут а вот с тем что вместо join делают несколько "простых" выборок - вместо него - повсеместно возьмем тот же catalog.section, который дергает getlist элемента, который "простыми запросами " дергает отдельно свойство поэлементно, отдельно цену и остаток поэлементно

и вроде не проблема, пока не появляется ску, который тоже поэлементно додергивается..