execute "CREATE EXTENSION IF NOT EXISTS pg_trgm;" execute "CREATE EXTENSION IF NOT EXISTS fuzzystrmatch;"

или сделайте своего пользователя суперпользователем :)

Заходите под супер пользователем и устанавливаете в ручную

давно помню пытался так, не катило, изменения как будто другой пользователь не видел

ребята кто в курсе что с сайто rubyjobs.ru случилось?

Ркн случился

Они хостятся на DO

Вот и задело

он даже под впн не заходит

Ркн случился

Роскомнадзор?

долго уже лежит?

только заметил

он даже под впн не заходит

Действительно

Добрый день. Подскажите пожалуйста по searchkick. Есть модель, ее надо инклюдить с другой, и после делать выборку по условием для связанной модели. Должно выглядеть примерно так first_m.search(include: :second_m, where: {second_m: {id: 1}}) Но что-то в блоке where не так написано. Просто, без серчкика выглядело бы так first_m.joins(:second_m).where(second_m: {id: 1}) Итак, вопрос получается в том, как писать условия в searchkick'e, для связанных таблиц. Конкретно — блок where

Добрый день. Подскажите пожалуйста по searchkick. Есть модель, ее надо инклюдить с другой, и после делать выборку по условием для связанной модели. Должно выглядеть примерно так first_m.search(include: :second_m, where: {second_m: {id: 1}}) Но что-то в блоке where не так написано. Просто, без серчкика выглядело бы так first_m.joins(:second_m).where(second_m: {id: 1}) Итак, вопрос получается в том, как писать условия в searchkick'e, для связанных таблиц. Конкретно — блок where

Проверь, что в where было именно название таблицы (в множесетвенном числе)

в коде так и пишу. в ошибке пишет Unknown where operator: :id

where: {positions: {id: 2112}} Блоке where у меня такой

Или может блок include как-то по другому пишется?

where: { “second_m.id” => 1 }?

where: { “second_m.id” => 1 }?

Так не ругается, но возвращает nil

всем привет! вдруг тут кто-нибудь #emacs использует: как выделить внутренности метода/блока (желательно через evil)?

where: { “second_m.id” => 1 }?

Ну и сам запрос пишет, который curl, в котором есть такой блок /_search?pretty -d '{"query":{"filtered":{"query":{"match_all":{}},"filter":{"and":[{"term":{"positions.id":2112}}]}}},"size":1000,"from":0,"fields":[]}' и nil

Про блок positions.id как будто вообще не знает

Добрый день. Подскажите пожалуйста по searchkick. Есть модель, ее надо инклюдить с другой, и после делать выборку по условием для связанной модели. Должно выглядеть примерно так first_m.search(include: :second_m, where: {second_m: {id: 1}}) Но что-то в блоке where не так написано. Просто, без серчкика выглядело бы так first_m.joins(:second_m).where(second_m: {id: 1}) Итак, вопрос получается в том, как писать условия в searchkick'e, для связанных таблиц. Конкретно — блок where

first_m.search(includes: %i[second_m], where: {second_m_id: 1 }) + в модельке scope :search_import, -> { includes :second_m } def search_data . . second_m_id: second_m.id end

что-то в этом стиле я бы сделал

что-то в этом стиле я бы сделал

Огромное спасибо, все получилось) Выручил

загвоздка была в том, что я метод seach_data не сделал

Переменные ${APP_HOST} лежат в .env

Нет, про YAML merge

«: *app

Только я хотел контролировать, от какого контейнера будет наследоваться конфигурация, через переменные среды (.env файл)

Типа <<: *${ENVIRONMENT}

У тебя один докер компос файл на все окружения?

Да

можно их разбить, я по крайней мере так и делаю docker-compose.dev.yml docker-compose.yml А потом уже, в .env фале пишу переменную COMPOSE_FILE=docker-compose.dev.yml

можно их разбить, я по крайней мере так и делаю docker-compose.dev.yml docker-compose.yml А потом уже, в .env фале пишу переменную COMPOSE_FILE=docker-compose.dev.yml

Да, про этот способ знаю. Мне было интересно, можно ли именно так, как я описал.

Приветствую, можете помочь куда копать, когда делаю result.joins(:category).select(:id, :name, :price, :brand_id, :category_id, "CONCAT(categories.name, ' ', gears.name) as title").map {|x| x.attributes} тогда показывает строку, но мне формат не подходит, а если убрать map тогда нету изминений, как сделать чтобы был AR ответ, но сконкатенированая строка

Если при передаче параметров не укажешь ключи, то получишь ошибку

гы первый раз так делаю link_to :отчет, url

гы первый раз так делаю link_to :отчет, url

Прям на русском?

прям рубям пофиг же

def ∑( a, b)

господа а чем нынче модно лечить вещи типа class Position < ApplicationRecord after_destroy do call_external_API(self) end end

а в чем болезнь?

def ∑( a, b)

эмодзи еще можно

а в чем болезнь?

модель лезет в куда-то наружу, извещать о своей смерти

ну... в том месте где удаляется call_external_API(object)

ну... в том месте где удаляется call_external_API(object)

и все? А если она удаляется вместе с родиетелем? Типа dependent :destroy

Смотря, что делает call_external_API

емнип, destroy вернет тебе удаленный объект

Просто frozen

Смотря, что делает call_external_API

вызывает внешний API

Это как бы понятно по названию

Это как бы понятно по названию

ну вроде как коллбэки AR - не место для подобного?

Коллбэки AR вообще зло

В любом случае апи лучше дернуть из условного сервиса, где дестроишь объект, чем из модели объекта

В любом случае апи лучше дернуть из условного сервиса, где дестроишь объект, чем из модели объекта

ЛОГИЧНО

Ну и

"А если она удаляется вместе с родиетелем? Типа dependent :destroy"?

берешь 500-700 баксов записываешься на курсы по ROR выходишь оттуда с довольно таки нормальными знаниями, устраиваешься на работу джуном или Мидлом (будет зависьть от того как хорошо ты работал на курсах) с первой зарплаты отбиваешь вложенные деньги и еще немного останется, со второй-третьей берешь себе макбук и все, ты теперь ROR разработчик

курсы это не панацея. Можно найти работу выучившись по доступным бесплатным источникам. Ну, наверное и так все это знают

"А если она удаляется вместе с родиетелем? Типа dependent :destroy"?

А как это мешает?

А как это мешает?

как ты дернешь условный сервис в таком случае?

?

ERROR: S client not available

курсы это не панацея. Можно найти работу выучившись по доступным бесплатным источникам. Ну, наверное и так все это знают

когда учишься сам по доступным бесплатным источникам тяжело отсеять релевантную информацию и best_practices (например) ты платишь на курсах за то, что это уже сделали до тебя и объяснили тебе простым (относительно) языком но никто не спорит, что работу так найти нельзя

?

есть некий условный User, который has_many Postions, которые удалятся каскадно вместе с удалением этого User. Как вызвать некий условный сервис в случае удаления Position таким образом?

Привет всем. Можно ли как-то сделать, чтобы Puma перезагружал воркеры поочередно автоматически? типа puma:restart, ибо памяти что-то поедает дико, подозреваю что это action_cable и приходится перезагружать пуму раза 3 в сутки

есть некий условный User, который has_many Postions, которые удалятся каскадно вместе с удалением этого User. Как вызвать некий условный сервис в случае удаления Position таким образом?

ты удаляешь user или position?

когда учишься сам по доступным бесплатным источникам тяжело отсеять релевантную информацию и best_practices (например) ты платишь на курсах за то, что это уже сделали до тебя и объяснили тебе простым (относительно) языком но никто не спорит, что работу так найти нельзя

сейчас также тяжело отсеять курсы, как и информацию - куда не плюнь курсы по программированию

есть некий условный User, который has_many Postions, которые удалятся каскадно вместе с удалением этого User. Как вызвать некий условный сервис в случае удаления Position таким образом?

изначально писать dependent :destroy оч херовая практика

есть некий условный User, который has_many Postions, которые удалятся каскадно вместе с удалением этого User. Как вызвать некий условный сервис в случае удаления Position таким образом?

Запрещай каскадом удалять, чисти все в сервисах, в чем проблема?

Привет всем. Можно ли как-то сделать, чтобы Puma перезагружал воркеры поочередно автоматически? типа puma:restart, ибо памяти что-то поедает дико, подозреваю что это action_cable и приходится перезагружать пуму раза 3 в сутки

https://github.com/schneems/puma_worker_killer

изначально писать dependent :destroy оч херовая практика

а вот тут можно поподробнее?

ты удаляешь user или position?

User. У него зависимые Position, которые тоже удалятся

и дёргаешь ты сервис с юзером?

Запрещай каскадом удалять, чисти все в сервисах, в чем проблема?

а зачем запрещать удалять каскадом?

а вот тут можно поподробнее?

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

и дёргаешь ты сервис с юзером?

никакого сервиса. Пишу user.destroy

а зачем запрещать удалять каскадом?

Чтобы не делать странные вещи.

https://github.com/schneems/puma_worker_killer

Видел, боялся его заюзать ) А вообще action_cable памяти много жрет? для чатов заюзал его

никакого сервиса. Пишу user.destroy

нууууу пардон, не сервис, а апи

туда передаётся что? юзер? позишн?

Чтобы не делать странные вещи.

а что странного в каскадном удалении?

Видел, боялся его заюзать ) А вообще action_cable памяти много жрет? для чатов заюзал его

в проде норм работает) насчет action_cable не подскажу

туда передаётся что? юзер? позишн?

позишн, естественно

Ты щас пытаешься решить проблему, которую можно избежать, если нормально спроектировать бизнес-логику. Это странно

Ты щас пытаешься решить проблему, которую можно избежать, если нормально спроектировать бизнес-логику. Это странно

а что ненормального в каскадном удалении?

Перечитай и задай правильный вопрос

Перечитай и задай правильный вопрос

из "бизнес-логики" здесь было упомянуто только каскадное удаление связанных записей

как надо "нормально" проектировать бизнес-логику в таком случае, и что "ненормального" в каскадном удалении?

если совсем приспичило, то можно приколхозить что-то в стиле positions = user.positions.to_a user.destroy positions.each { |position| call_external_API(position) } но это прям суперплохо, лучше всё-таки спроектируй нормально, да

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

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

а проще никак?

Куда проще?

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

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