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, а не напрямую в базу ходил. А пароли в клиентских приложениях хранить вообще не безопасно. Даже если вы как-то круто обфусцируете код - все равно не безопасно.
tasadar2, как и большинство серверов. Поэтому разрабатывать под Виндой особо смысла не имеет такие проекты. Советую в таком случае установить VirtualBox, в котором установить Linux какой-нибудь с графической оболочкой (тот же Mint Cinnamon можно) - и там работать.
tasadar2, так и писал бы сразу, что у тебя Винда) А то скидываешь видео, где настройка идет в Linux Mint Cinnamon. Ясное дело, в Винде иначе дело обстоит.
tasadar2, команду source venv/bin activate (проверь, точно ли правильно ее пишешь, есть ли пробел после source, например) надо запускать из той же директории, где была вызвана команда virtualenv venv. То есть в этом каталоге точно должна быть папка с названием venv. Проверь с помощью команды ls
NikSIk31, а тут дело совсем не в крутости или отсталости, на самом деле. Я вижу такие преимущества SPA-сайтов (я не конкретно про свой говорю, потому что разрабатываю его один, а вообще):
Бэкенд становится проще, потому что является обычным API - проще тестировать
Нет необходимости пилить отдельные API для мобильных приложений, потому что можно использовать то API, с которым взаимодействует фронтенд
Фронтенд полностью отделен от бэкенда, что позволяет фронтенд- и бэкенд-разрабам заниматься своими задачами независимо. То есть нет необходимости в fullstack-разработчиках
Возможность полностью переделывать фронтенд и бэкенд независимо, в том числе и переписывать бэкенд с пхп(например) на что-то другое, не трогая фронтенд вообще никак.
Возможность без боли использовать современные и удобные фронтенд-фреймворки, которые вкорячивать в не SPA-сайты бессмысленно и неудобно
Сайты в виде SPA работают приятнее, на мой взгляд, потому что нет перезагрузки страницы после почти любого действия. Везде можно все обвесить красивыми индикаторами загрузки, размытиями фона и т.п.
Если говорить о фронтенд-разработке, то в большинстве сайтов без SPA юзают jquery. С одной стороны, почему и нет. Но, с другой, когда на фронте усложняется какая-либо логика, поддерживать всю эту лапшу становится просто невозможно. Переписать нормально тоже не представляется возможным.
Насчет Тостера ничего не скажу, отталкиваюсь исключительно от своего опыта. К тому же везде по-разному. Гигант-Тостер не использует спа, а не менее гигант-Медуза использует, так что это совсем не показатель. :)
