cgvictor

По стопам поста Xekc-а, так внезапно появившегося в ленте... ;)

Итак, есть система. Которая цэ-мэ-эс, и, вроде бы, должна управлять контентом на сайте.
Про управление и подход читаем в вышеупомянутом же посте.

Аналогия с самолетом (xekc, ну молодца) более чем уместна.
В далекие шестидесятые еще считалось нормальным самому лезть под капот биплана и ключом подтягивать гайки цилиндров. Сейчас это будет выглядеть по меньшей мере странным.

Что же нужно? Нужно решение, которое позволит отслеживать и контролировать состояние системы на произвольном уровне абстракции.

( Мысли и рабочие скрины )

И снова в контексте "CMS и управления".

Покажите мне аналитика, который, будучи ответственен за аналитику и решения, доверит управление автоматизированной системе с чужими (=неизвестными) алгоритмами.

Даже я, хотя в мои функции аналитика входит лишь косвенно: пока не увижу всех входных данных, всех моделей развития и все предложенные методы воздействия, решение не приму. А вы о серьезных коммерческих задачах (с нескольконулевой стоимостью каждого хода) пытаетесь "протереть".

Удивлю кого-то еще больше: по очередной официальной статистике MS (это в контексте Office07 было, ну да ладно), функциями стат.анализа в Excel пользуются 4% из всех, кто собственно пользуется стат.анализом. Остальные переписывают функции вручную.
Так доверия больше.

(хотя в более серьезном ценовом сегменте - Axapta, SAP R3 - доверие к автоматике больше, т.к. там функции 1) открыты и 2) протестированы. Улавливаете?)

Похоже, что эти долбогрызы в Valuehost вырубают сервера так же, как юзеры - рабочие машины.
Т.е., пинком.

Бороться с их поведением и поведением их flock-а (который остается locked, если машину вырубают с пинка) мне категорически надоело.
А те вещи, которые подвергаются их вандализму, переписывать на базу ну никак не хочется.

В результате:
Написал мелкий класс, который реализует функционал, схожий с логикой SNAPSHOT_ISOLATION в SQL Server, да и в принципе с транзакционным подходом.

Для не знакомых с: SNAPSHOT_ISOLATION - режим изоляции таблиц данных до окончания транзакции без лок-блокировки. Операции чтения из других потоков во время исполнения изменяющей транзакции читают старые = не измененные ещё данные. Если транзакция заваливается, новые данные (не записанные или записанные частично) никак не влияют на старые, т.е. graceful rollback.

Из фич: перейти на новый код можно совершенно не затрагивая структуры файлов. "И было им всё, мягко говоря, побоку".

Принцип простой: версионность каждой записи.
Вроде работает. Счас буду гонять на реале.

По итогам (а какие могут быть итоги, если он в принципе завалиться не может?) может и выложу в ленту. В любом случае будет distributed freely.

"Заработался" - это когда ты полдня думаешь, как бы тебе написать некую хрень,
которую, на самом деле, ты написал три месяца назад...

Уж не знаю, кто дурак, но новый код при обкатке показал одну интересную вещь:
при запуске на запись пустого хранилища - оно (PHP) вылетает по переполнению буфера при обращении потом к любому другому объекту.

Затирает именно тот объем данных, который должен был быть записан в хранилище. Вылетает по out of memory (с ошибкой PHP), типа ему не хватило {указанного объема данных - у меня примерно 40-60 байт было} в выделенных 32 метрах. Которые там съесть невозможно ничем.

Где бага - пока не понял. Похоже, что-то с файловой системой, т.к. если закинуть изначально в storage хотя бы пустой файлик - работает как часы. Будет время - разберусь, механизм интересный...