Ты когда пишешь данные в бд на основе данных пришедших от юзера их нужно валидировать

под свою структуру и ожидания

любые данные не константы желательно валидировать

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

он не является пользовательскими данными

Он генерируется на основе данных юзера

ой блядь

как я устал. Ну я же написал выше

данные юзера надо проверять, да

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

может не до конца вник в проблему - но виртуальный атрибут не решит проблему?

wtf виртуальный аттрибут?

Тут Виталя проблема в том, что аттрибут в модели нельзя изменять в коллбеке before_validation

не феншуй якобы

пара методов в модели AR - геттер и сеттер. Его можно валидировать через стандартные AR sexy validations, например.

friendly_id gem вроде тому подтверждение что не феншуй

ибо аттрибуты он пишет как раз в before_validation

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

не вижу причины категорично не рекомендовать изменять аттрибуты в before_validation

У нас есть hidden_attribute

он генерируется на основе данных юзера

у нас есть юзер с правами can_change_hidden_attribute

у него в форме есть этот аттрибут

как ты будешь валидировать этот скрытый аттрибут для юзера я хз

https://github.com/norman/friendly_id/issues/660

а вот варить данные до валидации нормально

а че ты в гем скакнул

у тебя аргументы убежали чтоль.

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

ну очевидно что изменение данных перед валидацией может вызывать проблемы

Ну от контекста

поэтому зашёл в issues и нашёл первую попавшуюся проблему из-за этого

с турболинками так же, с spring так же, с N+1 проблемой так же

Все скрытые поля всегда собираю именно в before_validation

остальное в сеттере

если чтото постоянное то можно в before_save

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

ну пользователь может передать не корректные данные

нам надо их проверить же

да

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

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

это нормальная практика

а если ты переделываешь данные это можно в setter

гуд А что за телефон Вроде дроид, какой-нибудь miui?

Redmi note 3

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

то есть мы валидируем дефолтные значения?

а что там за оболочка такая странная?

мы валидируем значение которые пишутся в ДБ

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

у которого есть права записать это поле

ну ок

А вот я подумал

Без валидации нельзя решить эту проблему

Подключить uri

Спарсить то что вводит юзер

И если нету протокола добавить его

да, парсить/проверять надо в валидации

fish неплох

Это вот этот https://fishshell.com/

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

бе-бе-бе :-Р

очень уж созвучно с Ахматгилаев, скорее всего трудности перевода

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

Эт ты к чему?

очень уж созвучно с Ахматгилаев, скорее всего трудности перевода

Моя фамилия не такая)

я вот тоже сижу и думаю…

Всем привет, есть ли способ реализовать такое Есть страницы и есть категории c friendly_id, вот роуты resources :pages, only: :show, path: '' resources :categories, only: [:show, :index], path: ''

Народ подскажите. Пишу систему букинга. У меня есть расписание на неделю по дням. То есть каждый день недели имеет определенное время посещения. Мне надо бронировать это время и показывать что занято. Но если я буду создавать timetable на каждое время, каждого дня, каждой недели, каждого года, то бд очень быстро наберет миллионы записей. Как быть?

Антон

ERROR: S client not available

Народ подскажите. Пишу систему букинга. У меня есть расписание на неделю по дням. То есть каждый день недели имеет определенное время посещения. Мне надо бронировать это время и показывать что занято. Но если я буду создавать timetable на каждое время, каждого дня, каждой недели, каждого года, то бд очень быстро наберет миллионы записей. Как быть?

postgresql + elasticsearch + архивация старых записей

все равно это выйдет в гемор

ну так и задача не из простых)

Да и думаю что пока не наплодил эту бяку, думаю может изящнее решить

Получать расписание. Определять 7 дней вперед с числами и именами дней. Далее получать список броней с выборкой на дней вперед. И мержить полученные данные в мое расписание и только потом рендерить расписание в вью. Проверять

Я просто боюсь что логика проверки станет сложна и будет приличная задержка

так по идее 2 запроса плюс мержить парамы брони в календарь

тебе нужно определить наличие свободных дней ?

У меня есть расписание

На неделю

У каждого дня может быть рандомное время посещение

например 8-9 слотов

в 10 в 12 в 14 в 16 и тд

юзер может бронировать это время

Можно тупо создавать на каждое время запись в бд и ставить is_free:boolean

не

но клиентов будет 1000 например

и это по 10000 записей каждый день

быстро наберу миллионы

воу

10К записей в день?

один и тот же юзер может занять время уже занятое собой?

ну представь даже сейчас 100 клиентов, у каждого 10-20 контор. Каждая контора в день забирает 8-10 записей если я буду каждое время писать отдельно в табличку

100*10*10

А что мешает создавать только записи для забронированных времён и остальное считать свободным?

календарь

А что мешает создавать только записи для забронированных времён и остальное считать свободным?

ну я вот тоже об этом

ну вот например сегодня пятница

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

на двух инстнсах

10к записей фигня

ну так ты же календарь строишь независимо от занято/свободно просто ты заполняешь календарь на основе данных из бд