FK
Я просто с сайдкиком сталкивался с проблемами контроля джоб. Там даже jid доверять нельзя, на мой взгляд. Так что сайдкик только для того, что всегда должно сработать по принципу "выстрелил - забыл"
Size: a a a
2020 March 03
FK
Можно конечно просто джобу написать так, что бы она статус проверяла перед обновлением. Но тогда логика окажется размазана по нескольким местам.
В
Я просто с сайдкиком сталкивался с проблемами контроля джоб. Там даже jid доверять нельзя, на мой взгляд. Так что сайдкик только для того, что всегда должно сработать по принципу "выстрелил - забыл"
а почему нельзя доверять jid?
В
вроде как поиск джоб очень неэффективен
FK
Сложно сказать, он менялся при рестарте джоб. Я с этим сталкивался давно, и считаю что это был баг, но не проверял после что сейчас не меняется
NO
Советы👍
ES
Я просто с сайдкиком сталкивался с проблемами контроля джоб. Там даже jid доверять нельзя, на мой взгляд. Так что сайдкик только для того, что всегда должно сработать по принципу "выстрелил - забыл"
ES
Как кстати доклад, уже готов?
V
Вопрос: Есть модель User которая имеет много posts. подскажите как в AR получить одним запросом (чтобы без N+1) всех юзеров и к каждому юзеру его один последний Post ?
ds
Nikolay Okoneshnikov
Мужики, короткий вопрос:
Есть обращения граждан в простой форме, это обращение имеет "открыто", "на рассмотрении", "закрыто", на рассмотрение даётся 5 дней после вновь становится открытым, как лучше всего организовать в миграции?
Сейчас есть простой чекбокс (close:boolean) что открыто и закрыто, не пойму при случае с рассмотрением
Есть обращения граждан в простой форме, это обращение имеет "открыто", "на рассмотрении", "закрыто", на рассмотрение даётся 5 дней после вновь становится открытым, как лучше всего организовать в миграции?
Сейчас есть простой чекбокс (close:boolean) что открыто и закрыто, не пойму при случае с рассмотрением
Я б таймстамп хранил, до которого заявка открыта, а в модели можно кастомный геттер сделать который сравнивает значение из базы с текущим и возвращает буль. Так не нужно будет отложенных джобов никаких, которые могут и не отработать, через пять дней статус точно изменится и когда ты захочешь пять дней на десять поменять ты просто поменяешь константу без отмены и пересоздания неактуальных джобов
NO
Я б таймстамп хранил, до которого заявка открыта, а в модели можно кастомный геттер сделать который сравнивает значение из базы с текущим и возвращает буль. Так не нужно будет отложенных джобов никаких, которые могут и не отработать, через пять дней статус точно изменится и когда ты захочешь пять дней на десять поменять ты просто поменяешь константу без отмены и пересоздания неактуальных джобов
👍 тоже думал о таком подходе, буду разбираться
ds
Вопрос: Есть модель User которая имеет много posts. подскажите как в AR получить одним запросом (чтобы без N+1) всех юзеров и к каждому юзеру его один последний Post ?
без n+1 можешь сделать прелоад постов к юзерам и взять из них последний, но тогда куча лишних постов затянется. Тут мне кажется лучше без ар взять для каждого юзерайди последний пост и подтянуть к этим постам юзеров
AG
спасибо большое, помогло
вот такое теперь происходит при возвратах к странице, тоже с турболинками беда?
NO
Покажите js
NO
Используйте turbolinks:load ?
NO
Js файлы находятся в внутри тега <head> ? Выглядит будто перед закрытием body
AG
Nikolay Okoneshnikov
Используйте turbolinks:load ?
<%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
Есть генерация отчёта примерно 500 LoC очень связанного кода, причём ради производительности он был переписан на SQL без AR.
Теперь мне говорят пиши на него тесты.
Самое просто, что приходит в голову взять данных из продовой бд положить в фигчурез и подгружать перед тестом и чекать, что цифры на тех же данных те же получаются
Сел я писать дамп данных в yml и понимаю, что связанных таблиц штук 20 получается и это всё как-то муторно...
Другая гениальная идея, почисить БД оставить в ней записи только относящиеся к одному отчёту и в rspec before :suite делать pg_restore --data-only этих таблиц
Я пошёл к лиду и говорю вот, что ты про это думаешь? А он говорит нихрена я по этому поводу не думаю, погугли что там в инете пишут по поводу что делать "когда сложная структура тестовых данных нужна"
А вот мне кажется, что о таком не пишут, что если кто-то и использует успешно для тестов pg_dump/pg_restore, то никому об этом не говорит.
Теперь мне говорят пиши на него тесты.
Самое просто, что приходит в голову взять данных из продовой бд положить в фигчурез и подгружать перед тестом и чекать, что цифры на тех же данных те же получаются
Сел я писать дамп данных в yml и понимаю, что связанных таблиц штук 20 получается и это всё как-то муторно...
Другая гениальная идея, почисить БД оставить в ней записи только относящиеся к одному отчёту и в rspec before :suite делать pg_restore --data-only этих таблиц
Я пошёл к лиду и говорю вот, что ты про это думаешь? А он говорит нихрена я по этому поводу не думаю, погугли что там в инете пишут по поводу что делать "когда сложная структура тестовых данных нужна"
А вот мне кажется, что о таком не пишут, что если кто-то и использует успешно для тестов pg_dump/pg_restore, то никому об этом не говорит.
Что посоветуете?
AA
Есть генерация отчёта примерно 500 LoC очень связанного кода, причём ради производительности он был переписан на SQL без AR.
Теперь мне говорят пиши на него тесты.
Самое просто, что приходит в голову взять данных из продовой бд положить в фигчурез и подгружать перед тестом и чекать, что цифры на тех же данных те же получаются
Сел я писать дамп данных в yml и понимаю, что связанных таблиц штук 20 получается и это всё как-то муторно...
Другая гениальная идея, почисить БД оставить в ней записи только относящиеся к одному отчёту и в rspec before :suite делать pg_restore --data-only этих таблиц
Я пошёл к лиду и говорю вот, что ты про это думаешь? А он говорит нихрена я по этому поводу не думаю, погугли что там в инете пишут по поводу что делать "когда сложная структура тестовых данных нужна"
А вот мне кажется, что о таком не пишут, что если кто-то и использует успешно для тестов pg_dump/pg_restore, то никому об этом не говорит.
Теперь мне говорят пиши на него тесты.
Самое просто, что приходит в голову взять данных из продовой бд положить в фигчурез и подгружать перед тестом и чекать, что цифры на тех же данных те же получаются
Сел я писать дамп данных в yml и понимаю, что связанных таблиц штук 20 получается и это всё как-то муторно...
Другая гениальная идея, почисить БД оставить в ней записи только относящиеся к одному отчёту и в rspec before :suite делать pg_restore --data-only этих таблиц
Я пошёл к лиду и говорю вот, что ты про это думаешь? А он говорит нихрена я по этому поводу не думаю, погугли что там в инете пишут по поводу что делать "когда сложная структура тестовых данных нужна"
А вот мне кажется, что о таком не пишут, что если кто-то и использует успешно для тестов pg_dump/pg_restore, то никому об этом не говорит.
Охуенный лид