LL
Не, это именно переменные
Size: a a a
2021 May 04
M
Хм, да ты прав
LL
Мне ответили
> Yes, this is intentional. The parser forces pairs (with keywords or =>) to be written between %{}. We have no plans to relax this requirement for now. Thanks!
> Yes, this is intentional. The parser forces pairs (with keywords or =>) to be written between %{}. We have no plans to relax this requirement for now. Thanks!
M
Это то что в первом случае intentional?
LL
Не знаю
2021 May 05
M
Ну видимо да, потому что второй случай работает ожидаемым образом
AI
Ну x технически может быть парой, да
LL
Мне тут написали что типа это для
https://github.com/elixir-lang/elixir/issues/10964
unquote_splicing сделано. Но то что можно передать переменные, это ошибка, но всем насратьhttps://github.com/elixir-lang/elixir/issues/10964
AI
Ну как я и предполагал, да, дело в анквотах, переусложнять грамматику не захотелось поэтому можно любой идентификатор тоже
B
Есть array c JSON в каждом около 10-20к элементов, выиграю ли я что-то в производительности если запишу его через embed scheme как JSONB?
a
1. Валидация в эмбед схемах
2. Обращение к полям джсона прямо в SQL запросах (если речь, например, об SQL)
Иначе – нет. Только время на конвертации теряется
2. Обращение к полям джсона прямо в SQL запросах (если речь, например, об SQL)
Иначе – нет. Только время на конвертации теряется
ŹR
А какая альтернатива? Text?
NM
Может просто json?
B
ну альтернатива просто как rows в табличку.
B
просто json медленный будет.
NM
А просто rows нет? У вас там какие-то заранее известные поля?
B
Поля известные да, не динамические.
B
В принципи можно и другие варианты рассмотреть.
NM
А что вы хотите с этими данными делать? Хранить, искать по ним?
AD
Я сомневаюсь что jsonb в каком либо виде будет эффективнее чем просто rows