Результат деплоя - запущенный по переданной docker-compose спецификации кластер. В моем пример я открыл порт 80 на nginx и через публичный IP мог получить к нему доступ по 80 порту.
Яндекс сам позаботится о том, чтобы docker стартовал
Чтобы нельзя было определять подклассы в других файлах(вне класса). Главная задача DU - группировка вариантов, а создавая приватный конструктор, мы его делаем доступным только внутри нашего класса
Я посчитал, что для вводной статьи это много. Но если кого интересует, то напишу тут:
При удалении сервис должен сам проверить и обновить ссылаемые/ссылающиеся сущности: удалить их, поставить null или значение по умолчанию. Выбор действия зависит от ограничения в обозначенного в схеме. Это не относится к НЕ внешним ключам.
Например, если сущность, на которую мы ссылаемся ключом fk_id = '11111', удалится, то сервис обязан обновить наш ссылающийся ключ (в зависимости от типа отношений: проставить null, или удалить нас самих). Но если это поле зависит от другой сущности по бизнес логике не прописанной в схеме, то сервис не обязан делать обновления.
Грубо говоря, поведение при удалении описывается схемой.
Думаю да. Можно пройтись по основным подсистемам
Добавил ссылку на файл с циклом. Все действия происходят в нем
Если docker images ничего не выдает, то значит не получилось скачать образы. Предположения:
Неправильные названия образов: собираются и выгружаются одни, скачиваются другие (например, различные теги)
Для скачивания образов отсутствуют права (нужна авторизация)
Проверьте еще, что эти образы существуют в репозитории
Результат деплоя - запущенный по переданной docker-compose спецификации кластер. В моем пример я открыл порт 80 на nginx и через публичный IP мог получить к нему доступ по 80 порту.
Яндекс сам позаботится о том, чтобы docker стартовал
Заметил неоднозначность, спасибо
Это было вставлено, т.к. Rider ругается на отсутствие значения по умолчанию. На практике, конечно, он вряд-ли будет задействован
Чтобы нельзя было определять подклассы в других файлах(вне класса). Главная задача DU - группировка вариантов, а создавая приватный конструктор, мы его делаем доступным только внутри нашего класса
Академический интерес)
Я посчитал, что для вводной статьи это много. Но если кого интересует, то напишу тут:
При удалении сервис должен сам проверить и обновить ссылаемые/ссылающиеся сущности: удалить их, поставить null или значение по умолчанию. Выбор действия зависит от ограничения в обозначенного в схеме. Это не относится к НЕ внешним ключам.
Например, если сущность, на которую мы ссылаемся ключом fk_id = '11111', удалится, то сервис обязан обновить наш ссылающийся ключ (в зависимости от типа отношений: проставить null, или удалить нас самих). Но если это поле зависит от другой сущности по бизнес логике не прописанной в схеме, то сервис не обязан делать обновления.
Грубо говоря, поведение при удалении описывается схемой.
https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part1-protocol.html#sec_DeleteanEntity
Я работал в ООП парадигме, а C - язык процедурный)