а чье это?

а хз ушел кодер

наговнокодил и ушел

я думал шутки что так можна

так мне удалить эти методы?

наговнокодил и ушел

- нате вам канализацию в окно. всё, мне не звонить.

так мне удалить эти методы?

как хочешь

так а тогда вопрос

как хочешь

еслибы я знал что там выше

Какая-то дичь происходит $table->renameColumn('message', 'text'); бьет ошибку Unknown database type enum requested, Doctrine\DBAL\Platforms\MySQL57Platform may not support it.

странная фигня

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

еслибы я знал что там выше

А у тебя работает переименование text столбцов?

Всем привет. Что то никак не могу найти решение. Я подключил либу для хлебных крошек(davejamesmiller/laravel-breadcrumbs). Как можно переопределить эти хлебные крошки, что бы можно было назначать их отдельно от меню. То есть, на главном меню есть "Контакты" они же и в хлебных крошках. Но может можно создать отдельную страницу в админке и передавать в них. Я уже не все перерыл и ничего не получается найти, либо просто не понимаю. Может это можно сделать как то кастомно или переопределить можно. Нет ничего невозможного, но может кто-то ссылочкой поделиться какой-то или просто объясните...

А у тебя работает переименование text столбцов?

не пробовал

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

ты покажи как все это дело вызывается

Какая-то дичь. Если в таблице есть колонка типа enum, то в ней нельзя переименовывать другие столбцы? пиздец

че бля?

Сейчас откатил предыдущие миграции, убрал создание enum поля и успешно переименовал столбец

laravel 5.5, doctrine/dbal 2.8

а вообще, енум бесполезная фигня :)

Почему?

Почему?

оно зависимо от бд

и тогоже эфекта можно в коде добится просто со текст полями

что это значит? Что если я перейду с MySQL на PgSQL, то получу проблемы с совместимостью?

что это значит? Что если я перейду с MySQL на PgSQL, то получу проблемы с совместимостью?

не точно

но в стандарте нету типа enum

в SQL

Знал бы я об этом раньше)

а зачем вам понадобился enum?

хранить тип сообщения - $table->enum('type', [ 'text', 'document', 'image', 'service', ])->after('id');

хранить тип сообщения - $table->enum('type', [ 'text', 'document', 'image', 'service', ])->after('id');

вооьще костыль

Почему? как лучше?

хранить тип сообщения - $table->enum('type', [ 'text', 'document', 'image', 'service', ])->after('id');

ну и храните тип в отдельной таблице

вооьще костыль

а если нужно будет добавить тип сообщения?

ну и храните тип в отдельной таблице

вот так

обновлю enum, если это конечно возможно)))

вот так

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

- нате вам канализацию в окно. всё, мне не звонить.

Вроде всё верно сделал, но всё равно не робит... Хотя показывает, что successful

оффтоп, ребят, кто-то с бестхостинг работал?

Вроде всё верно сделал, но всё равно не робит... Хотя показывает, что successful

покаж код котрый вызывае а

image: php:7.2 pipelines: branches: develop: - step: name: Deploy to staging deployment: staging script: - bash pipeline.sh —— #!/usr/bin/env bash echo "bla" > /tmp/thisistest; #adf

ну и храните тип в отдельной таблице

Плодить таблицы, только ради одного поля такое себе

Да и смысл часто что бы именно в таблице иметь читаемое значение а не id

Да и смысл часто что бы именно в таблице иметь читаемое значение а не id

ну или не хранить список типов вообще

Мне енумы на стороне php нравятся на основе пакета https://github.com/myclabs/php-enum/blob/master/README.md

ага, я помню, что ты его уже кидал

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

В сеттерах атрибутов или в других методах можно тайпхинтингом контроль иметь, отличная штука

Ну и сахар в виде получения списка всех значений

Что такое таймхинтинг?

да обчный сахар для VO

контроль типа

type hinting

Плодить таблицы, только ради одного поля такое себе

довольно правильно ведь

довольно правильно ведь

Правильно для кого? По мне так не правильно.

Да и смысл часто что бы именно в таблице иметь читаемое значение а не id

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

Правильно для кого? По мне так не правильно.

для бд

Правильно для кого? По мне так не правильно.

с точки зрения нормализации, не?

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

Я на стороне пхп этот список храню

с точки зрения нормализации, не?

+, я вот читал про это

Я на стороне пхп этот список храню

это костыль

+, я вот читал про это

да и это удобно очень

да и это удобно очень

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

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

а мы в ларавель чате, унас орм :)

да и это удобно очень

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

Какая-то дичь происходит $table->renameColumn('message', 'text'); бьет ошибку Unknown database type enum requested, Doctrine\DBAL\Platforms\MySQL57Platform may not support it.

public function __construct() { DB::getDoctrineSchemaManager()->getDatabasePlatform()->registerDoctrineTypeMapping('enum', 'string'); } Вставь это в миграцию свою и получишь счастье

ERROR: S client not available

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

то есть, ты вообще считаешь, что нормализация не нужна?

то есть, ты вообще считаешь, что нормализация не нужна?

в пределах разумного

можно фио человека тоже в 3 разных сущности расхуярить, только это уже шизофрения

ок, логично

то есть, ты вообще считаешь, что нормализация не нужна?

Да причем тут нормализация? Ты список имён тоже выносишь отдельной таблицей?

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

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

парни, запишите себе сниппет выше, очень выручит, когда захотите миграцией поменять что-то в таблице с enum полем

можно фио человека тоже в 3 разных сущности расхуярить, только это уже шизофрения

фио ведь не те данные которые нужно подвергать нормализации, не?

Да причем тут нормализация? Ты список имён тоже выносишь отдельной таблицей?

тут спискок типов а не имен

фио ведь не те данные которые нужно подвергать нормализации, не?

зависит с какой целью. Например, если ты юзаешь автокомплит (на формах Тинькофф такая фишка есть) то удобно хранить библиотеку имен людей

парни, запишите себе сниппет выше, очень выручит, когда захотите миграцией поменять что-то в таблице с enum полем

Это конструктор миграции?

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

Вот когда ты знаешь что это список динамически изменяем, то естественно это отдельная таблица, но там и не одно поле будет. Мы значит захотим и тайсиамп поля там и мб софт делит и т. д. Это другая история

а особенно если для обращений их модифицировать

Это конструктор миграции?

да

Спасибо

зависит с какой целью. Например, если ты юзаешь автокомплит (на формах Тинькофф такая фишка есть) то удобно хранить библиотеку имен людей

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

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

а чойта нет, вполне себе способ экономии дискового пространства

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

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

утром нормализуем фио, вечером веники вяжем - нормальная история

а чойта нет, вполне себе способ экономии дискового пространства

а если имя будет прям вообще спецефичное и в базе его не будет? Че тогда?

insert into names

если БД упала - можно в кэш записать

если кэш не работает - смску админу отправить

если деньги на смс закончились - email

если инет недоступен - просто в лог насыпать

давай закончим этот бесполезный диалог, а?)

давай закончим этот бесполезный диалог, а?)

да, тож хотел предложить :)

ложки нет. таблицы неважны.

всем привет. помогите, пожалуйста, не отправляет пост запрос