Товарищи!

Кто может посоветовать модуль для сериализации объектов ?
Требования:
1) Кросплатформенность
2) Обратная совместимость - что бы при обновлении модуля, мы могли десереализовать объекты, сереализованные старой версией.
3) Малый размер сериализованных объектов..
4) Скорость как-никак.  (XML не предлагать)

Задумка такова: хранить в куках пользователя различные perl - объекты

Сейчас использую Storable.pm но недоволен, т.к. есть проблемы с совместимостью..
обновилась версия модуля на сервере (админы решили "помочь", например) - пользователи со старыми куками идут лесом.

Data::Dumper?

App::Serializer::Storable меня не подводил.

sir_nuf_nuf, сам я модули для сериализации не использовал, поэтому подсказать что-то хорошее не могу. Из Интернет-рекомендаций обратил внимание на JSON::XS.
По поводу Вашей затеи, насколько безопасно для системы хранить объекты на стороне пользователя? Чем такой подход лучше хранения данных на сервере?

Согласен с ginnie, я бы попробовал JSON.

А у вас не было проблем со Storable из-за того, что он сериализует данные в бинарный вид (т.е. имеются непечатные символы)? Это не отражается негативно на куках?

Да, достаточно безопасно. Это data-objects, ничего более. 

Чем лучше чем на сервере.. ну на сервере либо неперсистентно (memcached), либо из пушки по воробьям (БД), либо лишние траблы (BerkeleyDB). Cookie - самое - то =)



неа.. не было. По видиму модули для работы с куками Apache2::Cookie сами все эскейпят..


JSON::XS... хм.. попробуем =) скоро выложу сравнение производительности.

sir_nuf_nuf, чем cookie от memcached отличаются (наличие cookie тоже никто не гарантирует)?

куки - на совести клиента. если клиент параноик или девелопер и трет куки через 10 минут - мы бессильны (ну почти)
а вот выпадение из memcached - на нашей совести!

Добавлено через 1 минуту и 38 секунд
Товарищи! я фшоке =)




JSON::XS - в разы (5!) быстрее!

я еще нашел вариант серилизировать так








например, есть таблица в которой много столбиков и запрос идет сразу с 4-7 таблиц через LEFT JOIN и INNER JOIN, и на этой странице еще 3-5 запросов с разных таблиц и счетчики SUM и count()


это ресурсоемко для MySQL чтобы вытащить с разных таблиц + условия довольно не простые  и еще столбцов довольно много...

а для perl ресурсоемко формировать (инициализировать) хэши и массивы все время новые...



вот можно создать таблицу cache01 еще одну :

id  | time_cache_expires |  cache_data

time_cache_expires - время когда активынй хэш  
cache_data - в идеальном представлении серилизированный хэш (и/или хэщ-хэшей, массив-хэшей и т.д)

'SELECT cache_data from cache01 where id = ? AND time_cache_expires < '.time ;
такой запрос будет минималистический для MySQL...)?

или не изобретать велосипед, а лучше в строну memcache? 


вот тут вот есть еще какое-то кэширование http://search.cpan.org/~timb/DBI-1.609/DBI.pm#prepare_cached
с Tie::Cache::LRU:











Это сообщение отредактировал(а) gcc - 25.2.2010, 18:57

JSON::XS всем хорош, кроме следующего:

1. Он сериализует хеши/массива, но не объекты. Если надо восстанавливать информацию о том, что это был blessed hash - придётся дописывать обёртку. 
2. Он не умеет работать с рекурсивными объектами. Именно за счёт этого достигается наибольший % прироста скорости по сравнению сo Storable.
3. Если кодируете utf8 строки, возможно, придётся разбираться в том, в каком виде они вернутся/хранятся (с/без флага, байтами/символами).

А так я перешёл на него сo Storable для своего внутреннего обмена - никаких нареканий.