ну так вы сами ответили на свой вопрос. просто отрубят питающие линки и, чтоб уж наверняка, выдернут шнуры из бп! При этом правда отвалится РосКомАмазон, РосКомЦифровойОкеан и прочие, но это мелочи))
Мелкомягкие в своем репертуаре. За обнову заплатите немножечко бабла, для обновы мы у вас откусили 7 гигов винта насильно. И да, обнова будет немножечко кривая, но мы потом это исправим, возможно.
золотые слова. Очень часто заказчики сами не представляют как их бизнес работает, не говоря уже о том, чтобы внятно это кому-то объяснить. Но за ответ огромное спасибо вам и VolCh. Много для себя почерпнул.
Возможно я не совсем понятно объяснил разницу между этими двумя сущностями. На живом примере:
Обычная экскурсия "Прогулочный маршрут по центру столицы" можно купить билет и использовать его 1 раз в любой день в течении полугода с момента покупки.
Экскурсия с фиксированной датой "Прогулочный маршрут по историческим местам". Экскурсия проводится к примеру 16.05.2017, 23.05.2017 и 30.05.2017. Купить билет возможно на любую из этих трех дат при условии что дата еще не наступила и в желаемую дату есть свободные места. Использовать билет можно только в выбранную дату.
Контролем использования билетов занимается отдельная система, так что эта часть процесса в рамках задачи не важна
для начала я бы уточнил у того кто разбирается в предметной области является ли экскурсия с фиксированной датой просто экскурсией которая ограничена по времени или же это совершенно другая сущность с отдельным жизненным циклом.
Жизненный цикл фактически один и тот же. На практике разница выливается только в два момента:
обычная экскурсия может быть куплена в любое время, а экскурсия с фиксированной датой может быть куплена только при наличии свободных мест в желаемую дату
В билете на экскурсию с фиксированной датой указана дата проведения этой экскурсии.
Предположим что это не отдельная сущность а лишь опциональная характеристика экскурсии. Типа дэйт рэйндж за который оно действует. У остальных по умолчанию будет null-object с null-вым рэйнджем. Эту характеристику в силу ограничений СУБД я запихну в отдельную таблицу excursion_date. И в объектной модели будет соответствующая пропертя которую я буду использовать на запись.
Т.е. вы предлагаете сделать все экскурсии "как бы" с фиксированной датой, но у обычных экскурсий вместо даты/квоты будет null-object?
А если вы про случаи когда одну сущность мы по каким-то причинам поделили на две таблицы — я не знаю зачем так делать. Этим мы только себе в ногу выстрелили.
Полностью согласен про выстрел в ногу, но как бы вы поступили в следующей ситуации:
у нас есть сущность "Экскурсия" со своим списком полей и реляций и мы её продавали как товар. Грубо говоря одна экскурсия — одна строчка из таблицы "excursion" + по одной/несколько строк из связанных таблиц.
Потом кто-то захотел ввести дополнительно сущность "Экскурсия с фиксированной датой" и эта сущность от базовой отличается только наличием полей "дата проведения" и "квота". Теперь у нас товар не просто строчка из таблицы "excursion", а строчка из таблицы "excursion_date" плюс привязанная к ней строчка из таблицы "excursion".
Т.е. просто для какого-нибудь процесса вывода информации а-ля "вывести в какие даты доступна экскурсия N" можно использовать простую реляцию вида $excursionWithDate->getExcursionDates(). Но если нужно к примеру добавить экскурсию в корзину — то мне уже нужен объект собранный из двух таблиц.
Как бы вы поступили в этой ситуации?
P.S. знаю что бизнес-объекты рассматривать как строчки из таблицы нельзя, это было сделано для наглядности.
вы про абстрактный кеш в вакууме, а мы про кеш в yii2. сдается мне, что вы не до конца разглядели как и что возвращает кеш в yii. Ваши примеры имеют право на жизнь и они даже местами приятны взору, но разговор опять же о yii2
есть хоткей Alt+F1,1 выполняет ту же функцию.
хорошая иммерсионная ванна спасет и от тепловизоров
ну так вы сами ответили на свой вопрос. просто отрубят питающие линки и, чтоб уж наверняка, выдернут шнуры из бп! При этом правда отвалится РосКомАмазон, РосКомЦифровойОкеан и прочие, но это мелочи))
это просто горизонтальное масштабирование предусмотрено. патч-корды всунут — питание отрубят. всё продумано))
за чем патч-корды? присмотритесь повнимательнее. в 4х юнитах питание обрублено))
Мелкомягкие в своем репертуаре. За обнову заплатите немножечко бабла, для обновы мы у вас откусили 7 гигов винта насильно. И да, обнова будет немножечко кривая, но мы потом это исправим, возможно.
обратную зону стоит добавить, чтобы пинги шустрее шли
В dnsmasq та же задача решается путем добавления таких строк в стандартный конфиг
все поддомены вида *.nondv.home будут откликаться на 192.168.0.3
http://bgp.he.net/search?search%5Bsearch%5D=yandex&commit=Search
золотые слова. Очень часто заказчики сами не представляют как их бизнес работает, не говоря уже о том, чтобы внятно это кому-то объяснить. Но за ответ огромное спасибо вам и VolCh. Много для себя почерпнул.
понял. спасибо за разъяснения.
Возможно я не совсем понятно объяснил разницу между этими двумя сущностями. На живом примере:
Обычная экскурсия "Прогулочный маршрут по центру столицы" можно купить билет и использовать его 1 раз в любой день в течении полугода с момента покупки.
Экскурсия с фиксированной датой "Прогулочный маршрут по историческим местам". Экскурсия проводится к примеру 16.05.2017, 23.05.2017 и 30.05.2017. Купить билет возможно на любую из этих трех дат при условии что дата еще не наступила и в желаемую дату есть свободные места. Использовать билет можно только в выбранную дату.
Контролем использования билетов занимается отдельная система, так что эта часть процесса в рамках задачи не важна
Жизненный цикл фактически один и тот же. На практике разница выливается только в два момента:
Т.е. вы предлагаете сделать все экскурсии "как бы" с фиксированной датой, но у обычных экскурсий вместо даты/квоты будет null-object?
пардон, с разметкой немного ошибся
Прошу прощения за офтоп
Потом кто-то захотел ввести дополнительно сущность "Экскурсия с фиксированной датой" и эта сущность от базовой отличается только наличием полей "дата проведения" и "квота". Теперь у нас товар не просто строчка из таблицы "excursion", а строчка из таблицы "excursion_date" плюс привязанная к ней строчка из таблицы "excursion".
Т.е. просто для какого-нибудь процесса вывода информации а-ля "вывести в какие даты доступна экскурсия N" можно использовать простую реляцию вида $excursionWithDate->getExcursionDates(). Но если нужно к примеру добавить экскурсию в корзину — то мне уже нужен объект собранный из двух таблиц.
Как бы вы поступили в этой ситуации?
P.S. знаю что бизнес-объекты рассматривать как строчки из таблицы нельзя, это было сделано для наглядности.
А чем вас смущает новый синтаксис? Никто не запрещает по-старинке расписать все явно.
UPD: пардон, попутал с asset plugin