Здравствуйте, Poopy Joe, Вы писали:
PJ>Т.е. если файлы никому снаружи не нужны это рефакторинг или нет?
Нет, не рефакторинг. Они снаружи видны. Нужность — штука воображаемая: в вашем же примере они как будто бы были не нужны, и вдруг рраз! И стали нужны.

PJ>Изменил сигнатуру, делаешь что-то внутри с параметром, но тест про это вообще не в курсе. Замечательные тесты, да...
(facepalm). Простите, я уже расписал максимально подробно. Если вам непонятно, как именно рефакторинг взаимодействует с тестами — ну, попробуйте сами что ли.

PJ>Так у меня не менялись места внешних контрактов, но ты выше доказывал, что это никак не рефакторинг. Ты уж либо крестик сними, либо штаны одень.
Не любое изменение, не меняющее внешних контрактов, является рефакторингом.

PJ>Прелесть какая. Т.е. ты что-то зачем-то отдаешь клиентам, при этом ты даже не в курсе надо ли им это... А когда отдавать нечего, то просто начинаете врать выдавая фейковые данные...
Ну почему же фейковые — более-менее настоящие.

PJ>Откуда ты знаешь, ты же сказал, что клиенты внешние и ты не знаешь, что они делают и зачем? Может им критически важно знать различие между подпиской и покупкой.
Если важно — они всегда могут отличить их друг от друга по дополнительным признакам. Точно так же, как могут отличить подписки на Symantec от подписок на Dropbox.
Что мы знаем точно — это то, что у них не было задачи отличать подписки от покупок. Потому что никаких покупок раньше не было.
Если задача появится — у нас есть способ её решения, который мы предложим.

PJ>Т.е. ваша система получила зависимость от неизвестного чего-то, потому что там что-то может разъехаться, но точно ты не знаешь. Может и не разъехаться. И вообще хз, что там происходит...
А вы как думали? Всеведение — опасная иллюзия. Наиболее хреновые решения в моей практике принимали люди, котрые полагали, что им всё-всё известно.

S>>Убрать атрибут из выдачи — у кого-то упадёт ночная синхронизация с диагностикой "value cannot be NULL'.
PJ>Я не предлагал убирать никаких атрибутов, контракт он на то и контракт, чтобы оставаться валидным. Я уж не знаю как еще проще это сказать.
Вы пока вообще ничего хорошего не предложили. Идея "добавить ещё один контракт" плохая настолько, что у меня нет слов, чтобы подобрать описание для этого.

PJ>Вот эту бы всю энергию разума бы да на чтение.
PJ>По факту докладываю следующее. Это хардварная проблема. Это упомянуто, но, признаю, недостаточно внятно.
)))
PJ>Все файлы записаны, их можно даже считать обратно. Т.е. винда думает, что с файлами все ок.
)))
PJ>Но если машину после этого просто выключить, то в некоторых файлах могут быть нули, некоторые сектора не запишутся.
PJ>И нет, мы не идиоты, все что можно отключить в винде по этому поводу отключено. Вероятно это проблемы дискового кеша.
Ну конечно же это проблемы дискового кэша. Вы что думаете, вы первые в мире, кто столкнулся с такой ситуацией?
PJ>Это происходит нечасто, но происходит. Все остальные выводы которые ты навысасывал так же мимо кассы. Можешь не трудиться фантазировать остальные детали, какие диски брать или как правильно выключать винду и прочее. Считай это бизнес-требованием.
Пока что вы ничего нового не рассказали. Ровно то же самое, чего я ожидал. Единственное — что решения, которые я себе представлял, опираются на упорядоченность записи. Если бывает так, что произведённая позже запись проходит, а произведённая раньше — нет, то придётся покумекать над решением подольше. Сходу ничего придумать не могу — все известные мне технологии восстановления построены на упорядочивании. Если диск ухитряется записать хвост журнала, но теряет его середину, то это сломает каждую из известных мне СУБД.

Но это непринципиально: кто бы ни был виноват в потере данных, ОС или железо, при старте приложения мы наблюдаем одну и ту же картину — три типа файлов.