Чтобы в данной ситуации уничтожить контейнер, необходимо его остановить и удалить, но для начала, нужно узнать его ID:
Вместо этого можно использовать docker-compose stop для остановки всех контейнеров, либо docker-compose down для остановки и последующего удаления всех контейнеров.
А как быть с изменениями базы? Если у меня N сервисов, которые напрямую работают с таблицей юзеров, ведь потребуется вносить изменения в каждый из них, если будут проводиться серьезные изменения в БД?
Сейчас читаю "Создание микросервисов" Сэма Ньюмана, там нет явного запрета на использование такого подхода, но довольно подробно описываются риски при использовании общей БД — в том числе и изменения структуры. Опыта в этой тематике пока что мало, поэтому для начала решил сделать так: есть основная БД приложения, в которой хранятся все данные пользователей. Микросервисы, которые тоже должны работать с юзерами, просто получают необходимые данные при регистрации пользователя и обновляют их при изменении профиля.
Можно добавить бота @get_id_bot в нужный чат и выполнить команду /my_id@get_id_bot. После бота можно выпилить. Плюс, он умеет показывать ChatID нужного контакта.
Одно из пока что незадокументированных изменений — в конструкторах контроллеров теперь нельзя получить инстанс авторизованного юзера (и, скорее всего, любые другие инстансы, которые зависят от Middleware). Т.е. если в <= 5.2 вы где-то использовали такой код:
class HomeController extends Controller
{
protected $user;
public function __construct()
{
$this->user = Auth::user(); // Или auth()->user()
}
}
По-идее, если карта пропадает из поля зрения владельца, можно изначально предполагать вероятность, что с ней могли быть проведены деструктивные для держателя карты действия. Будьте внимательны)
Зачем использовать
func_get_arg(), если можно просто добавить аргументarray $attributesв саму фабрику?И для того, чтобы связанные модели создавались не внутри фабрик, а во время фактического создания главной модели, можно просто не вызывать
->create():Если в фабрику будет передан свой
user_id, то дополнительный пользователь создан не будет.Кажется не совсем поправили — сейчас там Azumuth вместо Azimuth.
Вместо этого можно использовать
docker-compose stopдля остановки всех контейнеров, либоdocker-compose downдля остановки и последующего удаления всех контейнеров.Пользуясь случаем попиарю свою реализацию API SDK — https://github.com/tzurbaev/laravel-forge-api :)
Видимо я неправильно вас понял, спасибо.
А как быть с изменениями базы? Если у меня N сервисов, которые напрямую работают с таблицей юзеров, ведь потребуется вносить изменения в каждый из них, если будут проводиться серьезные изменения в БД?
Сейчас читаю "Создание микросервисов" Сэма Ньюмана, там нет явного запрета на использование такого подхода, но довольно подробно описываются риски при использовании общей БД — в том числе и изменения структуры. Опыта в этой тематике пока что мало, поэтому для начала решил сделать так: есть основная БД приложения, в которой хранятся все данные пользователей. Микросервисы, которые тоже должны работать с юзерами, просто получают необходимые данные при регистрации пользователя и обновляют их при изменении профиля.
Можно добавить бота @get_id_bot в нужный чат и выполнить команду
/my_id@get_id_bot. После бота можно выпилить. Плюс, он умеет показывать ChatID нужного контакта.Стоит отметить, что Dependency Injection через конструкторы (в том числе контроллеров) по-прежнему работает.
Изменения касаются только конструкторов контроллеров. В других местах всё работает так же, как и прежде.
Одно из пока что незадокументированных изменений — в конструкторах контроллеров теперь нельзя получить инстанс авторизованного юзера (и, скорее всего, любые другие инстансы, которые зависят от Middleware). Т.е. если в <= 5.2 вы где-то использовали такой код:
то теперь это не работает.
Закончил на этом.