почему?

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

тупо дедупликация

опять непонятно почему это нельзя вынести на уровень приложения и пользоваться стандартным sql

какой у этой конструкции вообще юзкейс?

фильтрация контента

авторизация контента точнее :)

пользователям с айоса показывать это

с андроида не показывать

например

но там по сути бизнес правила

которые менеджеры сами правят

сложна

а то

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

все же напрямую можно достать из реквеста

платформу и гео

в БД правила хранятся

не пойму зачем

['==', '$platform', 'android']

вот правило не пойму зачем его катать в бд

а где его хранить?

логикой

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

и где эту логику держать?

Какую именно?

показывать или нет

в сервис вынеси логику

ну заебись

и у меня ляжет сервис от 10 RPM

и как мне определять что для этого контента использовать эту логику

а для того вот ту логику

сложна обьясняешь

но суть уловил

ты просто хранишь конфиг

чем jsonb не угодил

обычно туда конфиги складывают

нотификации и прочую дрянь

ну это не конфиг

ну как не конфиг

хотя с очень большой натяжкой можно и так назвать

Ты хочешь сказать что ты хранишь куски кода и вставляешь динамически куда то

ну как презерватив на голову натянут

типа функции высшего порядка

вот с такой натяжкой

там не конфиг

а бизнес-логика

в БД

я не уловил профит

в виде AST дерева

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

плюс нагрузка на БД низкая

из-за матчинга постгресовых интовых массивов

сколько у тебя RPM

потому-что есть GIN индексы

до 30К в пике

точеной

и ты с каждым запросом достаешь из бд эти правила

дроченой

и подставляешь нужные

да

он не достаёт из бд правила

оу

он говорит что достает

тогда всё ещё более непонятно

и типа через лиспу по дереву ему быстрее выполнить

чем прогнать сложную логику

ERROR: S client not available

и этим ты снижаешь нагрузку бд

?

я думал процедурой в бд делается

тут надо понимать и задачу и решение

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

так еще больше непонятно

в контенте есть ссылки на эти правила

ввиде массива прямо в каждой записе

integer array

https://github.com/uraimo/5110LCD_PCD8544.swift

Костя как бы намекает

чтобы я не пиздел лишнего :D

совсем нет

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

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

ja ja

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

ну это грубо

идея ясна

очень грубо, но да

ну круто че)

столько человекочасов убито)

соль именно в том что я могу фильтровать по этим правилам прямо в БД

мы просто походу о разной авторизации говорим :)

это нормально в полиморфик модели, в поле *_type хранить 'HomePage'(такой модели нет), и в экшне для главной странички Делать так, Review.where(*_type: 'HomePage')?

Нет

Правильно поменять в модели inheritance_column

Либо использовать другое название поля

Например *_kind

ну так понятней) спасибо

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

а где вообще можно узнавать о событиях?