чо можно на этом роре сделать того что нельзя сделать на известном ЯП ?

в мире веб разработок

а на нем другого и не пишут

рельсы умирающее старье

новых проектов на них мало пишут

70% сайтов в мире это вордпрес = PHP остается 30% на все остальные технологии

будем дальше вычислять долю rorr?))

а так первый yii с рельс очень многое позаиимствовал

никто не говорит что ror плохой)

70% сайтов в мире это вордпрес = PHP остается 30% на все остальные технологии

какое вранье

https://rb.ru/news/wordpress-25/

это только гугл и яндекс знают сколько сайтов на ВП

да косяк... видимо еще с мохнатых годов в голове цифра 70 засела

ну короче на руби все равно мало)))

Рельсы рулят, но по своему)

здраствуйте у меня с навбаром проблемы

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

если юзер гест, то кнопка login если нет то logout

шта?

а я хочу еще signup

засунуть туда

тернарный оператор

ты код то покажешь или нужно просить тебя показать?)))

вот

я хочу чтобы если юзер гест

показывало еще и signup

а так у меня ошибка

я хочу чтобы если юзер гест

вам же боженька дал visible в итемах

его бы и заюзали, один хрен

о божечки 😊

['label' => 'sign in', 'visible' => Yii::$app->user->isGuest]

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

ну это уже задрочерство будет, тут вопрос с операторами тяжко решается а тут вдруг феншуй

Всем привет! Я вот из комментов на хабре не понял - если обновится на 2.0.14, то теперь автоматом JSON-поля из базы будут переводится в обьекты? Просто много где юзаю уже их, и там вручную туда и обратно перевожу.

а у меня на серверах все еще mysql 5.6 везде :(

И все таки, кто-нибудь может объяснить почему Json в структурированных данных? И какой он даст профит по сравнению с обычным отношением и выделенной таблицей?

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

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

Проще

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

Для структурированных же 👆

Так что, теперь убирать всюду парсинг?

Блин

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

И все можно спроектировать нормально

А для остального noSql

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

С этим надо будет как-то работать в будущем, все равно прийдётся структурировать

Если бы так было. никто б не делал такой тип поля в базах

КОроче, я так понял, нужно переделать это все. Мда, не очень то обратносовместимо

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

Это частный случай, как часто вам встречаются не структурированные данные?

Это частный случай, как часто вам встречаются не структурированные данные?

прям щас с ними сижу лицом к лицу. есть построитель отчетов, в нем несколько типов отображения данных, у каждого типа есть json-конфижка для всяких цветов, шрифтов, серий

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

СТРУКТУРИРОВАННЫЕ

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

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

Ну вот конфижки и есть noSql

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

взрыв шаблона 😬

ну так понятно, но если есть возможность хранить их в json-поле, почему ею не воспользоваться?

по моему это сложнее (

взрыв шаблона 😬

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

ну так понятно, но если есть возможность хранить их в json-поле, почему ею не воспользоваться?

Конфиги не структурированные

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

И это ок

Странно откуда такой интерес) это не так часто встречается и вроде попаболью никогда не отзывалось

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

так есть же динамические поля ) и кеширование

так есть же динамические поля ) и кеширование

кэширование-то здесь каким боком?))

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

И все таки, кто-нибудь может объяснить почему Json в структурированных данных? И какой он даст профит по сравнению с обычным отношением и выделенной таблицей?

скорость

['label' => 'sign in', 'visible' => Yii::$app->user->isGuest]

Спасибо!

скорость

В - поддерживаемости?

В - поддерживаемости?

в выборке

в выборке

В минус поддерживаемости кода

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

может, оно и к лучшему

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

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

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

Не, это было но в десктопе 😊

json ок для eav

а то заебался бы для каждой опции свои поля лупить

а то заебался бы для каждой опции свои поля лупить

А проблемы с поиском не смущают? )

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

Отличная идея для нового фреймворка

А проблемы с поиском не смущают? )

По Json можно искать в новых версиях mysql