может такое вообще не комильфо миграциями а только средствами sql?

Миграции это система контроля версий БД

какая засада в самой laravel если все делать без миграцией и таскать дампами?

Всегда есть смысл

да я понимаю все что бы в гит закачать..

Миграции нужны для того, чтобы можно было хранить структуру БД в гите

какая засада в самой laravel если все делать без миграцией и таскать дампами?

Из личного опыта - тупая идея

но в гит можно и sql файлик положить?

какая засада в самой laravel если все делать без миграцией и таскать дампами?

Засада начнется в тот момент, когда над проектом параллельно начнет работать несколько людей

Там не просто файлик, вам придётся придумывать свой формат миграций

Засада начнется в тот момент, когда над проектом параллельно начнет работать несколько людей

ну это тока в теории. Реальное два человека

"Накатываем это, откатываем это"

ну это тока в теории. Реальное два человека

Ты создал таблицу, он создал таблицу

Как поступать будете?

Если миграции, то проблем ноль

Ты создал таблицу, он создал таблицу

а ну да.. а если прокатить при этом весь дамп то вся база рефрешнеться вообще..

а так миграциями добавим только табличку..

Ещё ситуация Локально добавили таблицы На проде как их потом добавите?

ну а как миграции работают в случае если много данных в некоторой таблицах до млн?

ну это тока в теории. Реальное два человека

Даже двум людям без git и миграций очень сложно делать что-либо паралельно

Без миграций вам всё то же самое придётся делать, только руками

Даже двум людям без git и миграций очень сложно делать что-либо паралельно

git понятное есть..

ну а как миграции работают в случае если много данных в некоторой таблицах до млн?

Не вижу связи между количеством данных и миграциями

git понятное есть..

Есть проекты где и этого нету. Просто древнючий проект внутреннего биллинга

git понятное есть..

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

Если надо добавить столбец в таблицу с миллионами записей - то вы будете руками, а не миграцией, исполнять sql-запрос. А потом бить того, кто прибумал такую архитектуру )

А как принято работать с миграциями когда на проде туча данных?

А как принято работать с миграциями когда на проде туча данных?

Так и работать

я в том плане что все млн строк на dev все равно не будешь копировать..

Так и работать

со структурой то понятно

а с данными?

Смотря что надо

а это вопрос не к миграциям, а к организации работы. Если надо держать данные в локале - держите данные

а это вопрос не к миграциям, а к организации работы. Если надо держать данные в локале - держите данные

а если не надо?

Значит не держите )

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

так их дампами и таскать?

Тут похоже непонимание того, что такое миграции

я понимаю

они для структуры

и для гит

к данным отношения не имеют

они для структуры

Там а при чем тут данные?

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

Миграции заведуют струкрутой данных, а не данными

Для заполнения данными можно сделать seed

Там а при чем тут данные?

ну вот мне и интересно как опытные люди в этом случае с данными решают.. структурой заведуют миграции. А данные уже в эту структуру просто дампом?

Для заполнения данными можно сделать seed

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

если нужны даные с прода, делается дамп с прода и дальшенакатываются на него миграции, которых в нём ещё нет. там есть папка migrations, где указывается, что на него накачено. В этом ещё один плюс миграций laravel.

у меня еще завязано на структуру mp3 файлов.. мне особо нет смысла нагенерить тестовые данные для dev тк мне нужны id-ники указывающие на файлы на файловом сервере

ну и картинки тоже отдельно лежат и нужны реальные id

а не сидированные тестовые данные

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

если нужны даные с прода, делается дамп с прода и дальшенакатываются на него миграции, которых в нём ещё нет. там есть папка migrations, где указывается, что на него накачено. В этом ещё один плюс миграций laravel.

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

впрочем это наверное уже когда и на проде ларавель и миграции. мне до этого далеко поэтому не актуально

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

ну вообще достаточно большой

на проде пока нет никакой ларавель

там просто старый php сайт. гит только есть но это не причем

там отдельно сервер с сайтом, отдельно с БД, отдельно с файлами. Ларавель нигде нет и на старом сайте не будет

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

Просто ради того что бы дамп туда сюда не таскать?

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

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

структуру созданную миграциями на локали. я переношу на прод в отдельную БД, что бы там удобнее было данными наполнять.. это логично?

Если хочешь начать добавлять фичу миграций (не ларавеловских, а просто) - то первой миграцией будет создание текущей структуры бд и, возможно, отдельно sql для накатывания данных. а потом все изменения пиши в файлах, где будет up и down

и накатывать-откатывать все будете руками

ERROR: S client not available

отошёл

подумаю.. то есть создать миграциями на старом сайте структуру старой БД.. да это геморно.. там такая распухшая и кривая структура..

да и вообще на старом сайте мне кажеться миграции не нужны...

да и вообще на старом сайте мне кажеться миграции не нужны...

не нужны

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

ну вот в черновике типа такого..

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

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

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

function ($query) use ($data)

function ($query) use ($data)

боже, великолепно

боже, великолепно

Это не боже, это замыкание

Это не боже, это замыкание

Божественное замыкание

Привет. Может кто встречал, OSX High Sierra, вчера после brew update мускул просто перестал работать, на все инсерты отваливается (SQLSTATE[HY000] [2006] MySQL server has gone away)

Привет. Может кто встречал, OSX High Sierra, вчера после brew update мускул просто перестал работать, на все инсерты отваливается (SQLSTATE[HY000] [2006] MySQL server has gone away)

Логи же

Логи же

Логи пишут что превышен максимальный пакет, думал грешить на себя, что затер чтото, полностьбю переставил ОС - тоже самое

Логи пишут что превышен максимальный пакет, думал грешить на себя, что затер чтото, полностьбю переставил ОС - тоже самое

Ну вот попробуй загуглить ошибку

Ну вот попробуй загуглить ошибку

Все ответы таковы: увеличить в конфиге max_allowed_packet

Уже проделывал это

Я сомневаюсь что дефолтные миграции лары жрут вот столько

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

парни, а ни кто не знает. На одном хостинге видел. Ошибки php пишутся в файл рядом с php файлом. Не знаете как такое настроить или может видели где?

парни, а ни кто не знает. На одном хостинге видел. Ошибки php пишутся в файл рядом с php файлом. Не знаете как такое настроить или может видели где?

В настройках nginx, как вариант

Здравствуйте. У меня такая проблема - при обновлении поля, если написать больше 255 символов - ошибка illegal offset type. Это проблему можно решить валидацией?

Здравствуйте. У меня такая проблема - при обновлении поля, если написать больше 255 символов - ошибка illegal offset type. Это проблему можно решить валидацией?

Да

Max:255

Спасибо :)

https://stackoverflow.com/questions/31330092/laravel-5-join-on-with-in-query

Мерси

Вопрос по архитектуре. Есть таблица телефонов Есть таблица пользователей Есть поиск пользователя по телефону, он используется в нескольких местах. Куда эту логику разместить?