| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > сериализация и модификаторы доступа к свойствам |
| Автор: setnull 22.6.2013, 20:46 |
| Все здравствуйте. Приложение использует хранение сериализованных объектов и, естественно, их восстановление. В процессе эволюции, модификатор доступа одного из полей (member1) претерпел изменения protected/public; Итоге появилось две группы сериализованных версий объектов. Собственно, содержащие записи: "member1" и "*member1". Уверен, можно выделить еще группу объектов с утерянными данными, прошедших несколько циклов сериализации/структуризации, но речь сейчас не о них... как корректно привести все имеющиеся объекты к единому виду, не прибегая к классификации каждого сериализованного представления путем анализа ? 1. Допустимо ли перед структуризацией просто применить str_replace('"*member1"', ''"member1"', $serialData) к сериализованному представлению и быть уверенным, что непосредственно в экранированных представлениях строк комбинации '"*member1"' быть не может, или я чего-то не учел? 2. Есть инструменты, на ряду с __wakeup , дающие более гибкий контроль над процессом структуризации, что-то вроде __onWakeUpMember($dataName, $dataValue, $structedField, $structedValue)? Спасибо!!! |
| Автор: setnull 22.6.2013, 22:26 |
| или даже может стоит ориентироваться на ';"*member1"' ? и можно предполагать и быть уверенным, что свойство member1 будет одинаково единообразно соблюдать свою очередность во всех представлениях и не будет вынесено в представлении первым, или могут быть нюансы? (к примеру, что первое в голову приходит - пхп в принципе не гарантирует сохранение очередности полей в сериализованных представлениях - какой-нибудь вариант со значениями свойств по-умолчанию, при которых свойство просто не включается в сериализуемое представление, что может обусловить просто выпадение всех свойств, предшествующих member1, из представления, что выведет member1 в нем на первую позицию а, и в любом случае размер нужно тоже изменить получается ;s:{N}:"*member1"' ;s:{N-1}:"member1"' такой заменой возможно однозначно решить проблему? |
| Автор: setnull 22.6.2013, 23:31 |
| p.s. последовательность нужна не просто 2A * , а 00 2A 00 .*. |
| Автор: Fortop 24.6.2013, 23:27 | ||
Пересохраните объект если у него изменились сигнатуры методов. Вы должны предусматривать это в процессе "эволюции". |
| Автор: ksnk 24.6.2013, 23:53 |
| Разумнее переключится на методы __sleep и __wakeup, или даже прикрутить к объекту serializable интерфейс. Там можно управлять данными более гибко, например с "номером версии" и так далее, как самому придет в голову ;) Единственная тонкость - переход от обычного метода сериализации к новому. Возможно, нужно сначала определить только метод __sleep (serialize) и подгрузить комплект объектов обычным образом, после чего сохраниться уже по новому. Потом определить __wakeup(unserialize) и жить уже так. |
| Автор: setnull 27.6.2013, 13:38 |
| 2 Fortop, ksnk предусмотреть в процессе эволюции уже не удалось... задача стоит непосредственно в том, чтоб единообразно структурировать оба вариантов имеющихся представлений. чтоб пересохранить, первоначально нужно открыть образ, часть которых не открывается.... касательно __wakeup, насколько я понимаю непосредственной возможности скорректировать процесс структуризации он не дает, просто можно отловить событие пробуждения и совершить дополнительные действия, опираясь на уже имеющиеся на руках распакованные данные... но именно вмешаться в процесс распаковки - не дает... кстати, было бы удобно, хотя бы в аргументах получить сериализированное представление, из которого производилось восстановление... т.е., как я понимаю, __wakeup в данной задаче не поможет |
| Автор: ksnk 27.6.2013, 14:18 | ||
| setnull, Ага! То есть есть файл охранения состояния, который уже является невалидным и не грузится естественным образом системой? Видимо, модификация сериализованных данных в текстовом редакторе - единственная доступная альтернатива для сохранения результатов.
Видимо, да. serializable, в дальнейшем, позволит сохраняться независимо от изменяемой структуры класса. |
