Ignatiy2 Если не хочешь с настройкой всего этого заморачиваться, установи себе в Винде OpenServer/Wamp/Xampp/Denwer (если он не помер еще) - что-то из этого.
Anton Semenov, так что мешает запихать результаты запроса в кеш? Вытаскиваться оттуда они будут в разы быстрее.
Еще есть вариант попробовать в условия связывания таблиц запихать некоторые условия из where. Например:
Вместо JOIN wp_postmeta AS pm ON (p.ID = pm.post_id)
Сделать
JOIN wp_postmeta AS pm ON (p.ID = pm.post_id AND pm.meta_key = 'fave_property_id' AND pm.meta_value in (70441,70451,70481,70482,70483,70501))
P.s. а учитывая что база почти 1 Гб, странно, что запрос медленно работает. Дело в том, что 1 Гб для современных баз данных - это крайне мало.
Durin Qurkingo, так а что конкретно не понятно? Я понял это так:
useSelector - это, грубо говоря, маппинг значения из стора на переменную. Но "хитрый" маппинг, благодаря которому изменения в этом значении в стор приведут к перерисовке компонента, в котором вызван useSelector для этого значения стора.
useStore - получение стора целиком (где конкретно такое может пригодиться - не знаю, потому что обычно требуется useSelector для конкретных значений).
useDispatch - ссылка на функцию dispatch редакс стора. Нужно, чтобы диспатчить экшены
Anton Semenov, ну не совсем, потому что сам запрос непосредственно в кеш не засунешь же. Надо сделать выборку этим запросом без условия pm.meta_value in (70441,70451,70481,70482,70483,70501). После этого по полученному массиву (который является набором данных, которые вернул этот запрос) пройтись циклом, и на основе PID (pm.meta_value) сформировать ключи для кеша - и записать в него строки этого массива (например, сериализовав их).
После этого, вместо выполнения этого сложного запроса к базе, надо вытаскивать данные из кеша по ключам и десериализовывать их - это будет гораздо быстрее, чем выполнять тяжелый запрос к базе. Периодически значения в кеше надо обновлять, если требуется.
Anton Semenov, а есть вариант закешировать результаты этого запроса в мемкеш или Redis, но без условия pm.meta_value in (70441,70451,70481,70482,70483,70501)? Ключами сделать meta_value_70441, meta_value_70451 и т.д. И выборку делать не из базы, а из кеша?
dospayne2, так уберите пароль от базы из скрипта и сделайте возможность при запуске скрипта указывать путь к конфигурационному файлу через параметр командной строки. Те, кто знает пароль от базы, создадут такой файл, впишут в него пароль от базы - и без проблем запустят скрипт. Если же надо давать людям скрипт на питоне, но при этом скрывать прямо внутри него пароль от базы, то это вообще не безопасный вариант - что-то делаете не так. Надо тогда, чтобы с базой взаимодействовал api-сервис, а ваш питон-скрипт делал к нему обращения по http, а не напрямую в базу ходил. А пароли в клиентских приложениях хранить вообще не безопасно. Даже если вы как-то круто обфусцируете код - все равно не безопасно.
NikSIk31, а тут дело совсем не в крутости или отсталости, на самом деле. Я вижу такие преимущества SPA-сайтов (я не конкретно про свой говорю, потому что разрабатываю его один, а вообще):
Бэкенд становится проще, потому что является обычным API - проще тестировать
Нет необходимости пилить отдельные API для мобильных приложений, потому что можно использовать то API, с которым взаимодействует фронтенд
Фронтенд полностью отделен от бэкенда, что позволяет фронтенд- и бэкенд-разрабам заниматься своими задачами независимо. То есть нет необходимости в fullstack-разработчиках
Возможность полностью переделывать фронтенд и бэкенд независимо, в том числе и переписывать бэкенд с пхп(например) на что-то другое, не трогая фронтенд вообще никак.
Возможность без боли использовать современные и удобные фронтенд-фреймворки, которые вкорячивать в не SPA-сайты бессмысленно и неудобно
Сайты в виде SPA работают приятнее, на мой взгляд, потому что нет перезагрузки страницы после почти любого действия. Везде можно все обвесить красивыми индикаторами загрузки, размытиями фона и т.п.
Если говорить о фронтенд-разработке, то в большинстве сайтов без SPA юзают jquery. С одной стороны, почему и нет. Но, с другой, когда на фронте усложняется какая-либо логика, поддерживать всю эту лапшу становится просто невозможно. Переписать нормально тоже не представляется возможным.
Насчет Тостера ничего не скажу, отталкиваюсь исключительно от своего опыта. К тому же везде по-разному. Гигант-Тостер не использует спа, а не менее гигант-Медуза использует, так что это совсем не показатель. :)
NikSIk31, добрый день! Не очень понял, когда именно происходит перезагрузка. При переходе на статью из общего списка перезагрузки нет (в браузере не вращается индикатор загрузки страницы). Если Вы имеете в виду переход по ссылке в тексте статьи - да, такая проблема есть, там, действительно, происходит перезагрузка.
Дело в том, что для работы таких ссылок без перезагрузки страницы, их надо парсить их текста статьи на стороне фронтенда и рендерить как react-компоненты (сейчас это обычный тег ). А текст статьи вместе с такими ссылками у меня сейчас приходит с сервера и вставляется в страницу полностью с помощью dangerouslySetInnerHTML без какой-либо обработки в js.
Ivan Yakushenko, интерпретатор Питона потребуется, pip потребуется. Возможно, и Virtualenv. Можно установку всего этого вшить в bat-скрипт, но это как-то так себе, мне кажется. Вообще есть, вроде как, утилиты, которые умеют питон с зависимостями упаковывать в исполняемый файл, но я не пользовался - не могу ничего сказать.
habrahabraman, если кода мало достаточно, я бы это на го переписал (если это более-менее выгодно и не сильно запарно). Не потому, что я этот язык люблю, а просто на выходе получаешь бинарь, который заказчик даблкликом запустит - и ничего доустанавливать ему не придется.
