Все здравствуйте.

Приложение использует хранение сериализованных объектов и, естественно, их восстановление.

В процессе эволюции, модификатор доступа одного из полей (member1) претерпел изменения protected/public;
Итоге появилось две группы сериализованных версий объектов. Собственно, содержащие записи:
   "member1"
и "*member1".

Уверен, можно выделить еще группу объектов с утерянными данными, прошедших несколько циклов сериализации/структуризации, но речь сейчас не о них...

как корректно привести все имеющиеся объекты к единому виду, не прибегая к классификации каждого сериализованного представления путем анализа  ?

1. Допустимо ли перед структуризацией просто применить str_replace('"*member1"', ''"member1"', $serialData) к сериализованному представлению и быть уверенным, что непосредственно в экранированных представлениях строк комбинации '"*member1"' быть не может, или я чего-то не учел?
2. Есть инструменты, на ряду с __wakeup , дающие более гибкий  контроль над процессом структуризации, что-то вроде __onWakeUpMember($dataName, $dataValue, $structedField, $structedValue)?


Спасибо!!!

Это сообщение отредактировал(а) setnull - 22.6.2013, 23:06

или даже может стоит ориентироваться на

';"*member1"'
?
и можно предполагать и быть уверенным, что свойство member1 будет одинаково единообразно соблюдать свою очередность во всех представлениях и не будет вынесено в представлении первым, или могут быть нюансы?
(к примеру, что первое в голову приходит
- пхп в принципе не гарантирует сохранение очередности полей в сериализованных представлениях
- какой-нибудь вариант со значениями свойств по-умолчанию, при которых свойство просто не включается в сериализуемое представление, что может обусловить просто выпадение всех свойств, предшествующих member1, из представления, что выведет member1 в нем на первую позицию

а, и в любом случае размер нужно тоже изменить
получается
;s:{N}:"*member1"'
;s:{N-1}:"member1"'

такой заменой возможно однозначно решить проблему?

Это сообщение отредактировал(а) setnull - 22.6.2013, 23:13

p.s.
последовательность нужна не просто
2A * , 
а 
00 2A 00  .*.

Пересохраните объект если у него изменились сигнатуры методов.

Вы должны предусматривать это в процессе "эволюции".

Разумнее переключится на методы  __sleep и __wakeup, или даже прикрутить к объекту serializable интерфейс. Там можно управлять данными более гибко, например  с "номером версии" и так далее, как самому придет  в голову ;)
Единственная тонкость - переход от обычного метода сериализации к новому. Возможно, нужно сначала определить только метод __sleep (serialize) и подгрузить комплект объектов обычным образом, после чего сохраниться уже по новому. Потом определить __wakeup(unserialize) и жить уже так.

2 Fortop, ksnk
предусмотреть в процессе эволюции уже не удалось...
задача стоит непосредственно в том, чтоб единообразно структурировать оба вариантов имеющихся представлений.
чтоб пересохранить, первоначально нужно открыть образ, часть которых не открывается....

касательно __wakeup, насколько я понимаю непосредственной возможности скорректировать процесс структуризации он не дает, просто можно отловить событие пробуждения и совершить дополнительные действия, опираясь на уже имеющиеся на руках распакованные данные... но именно вмешаться в процесс распаковки  - не дает... кстати, было бы удобно, хотя бы в аргументах получить сериализированное представление, из которого производилось восстановление...
т.е., как я понимаю, __wakeup в данной задаче не поможет

setnull, Ага! То есть есть файл охранения состояния, который уже является невалидным и не грузится естественным образом системой?
Видимо, модификация сериализованных данных в текстовом редакторе - единственная доступная альтернатива для сохранения результатов.


Видимо, да.

serializable, в дальнейшем, позволит сохраняться независимо от изменяемой структуры класса.