MessagePack::OPT_PHPONLY on false - object serialized to array without keys

[msgpack]

MessagePack::OPT_PHPONLY on false - object serialized to array without keys

[wookieb]

What about this bug? It's pretty important for me. Without fix we can't use msgpack as serialization format to exchange data between different programming environments.

[laruence]

<?php
class Test {
        private $privateProperty = 'some value';
            protected $protectedProperty = 'some value';
            public $property = 'some value';
            public function toArray() {
                return get_object_vars($this);
            }
}

$o = new Test();
$msgpack = new MessagePack(false);
print_r($msgpack->unpack($msgpack->pack($o->toArray())));

Array
(
    [privateProperty] => some value
    [protectedProperty] => some value
    [property] => some value
)

[wookieb]

I can do it via reflection. But I think it's not a right way to do serialization using serialization tool :)

[kjdev]

what about in the way: https://github.com/kjdev/php-ext-msgpacki

$o = new Test();
$msgpack = new MessagePacki(MSGPACKI_MODE_ORIGIN);
print_r($msgpack->unpack($msgpack->pack($o)));
/*
Output:

Array
(
    [privateProperty] => some value
    [protectedProperty] => some value
    [property] => some value
)
*/

$msgpack = new MessagePacki(MSGPACKI_MODE_PHP);
print_r($msgpack->unpack($msgpack->pack($o)));
/*
Output:

Test Object
(
    [privateProperty:Test:private] => some value
    [protectedProperty:protected] => some value
    [property] => some value
)
*/

[wookieb]

@kjdev I use it right now (btw good work!) :) But even when I use msgpacki there is still a bug in "official" msgpack extension for php. Maybe it's time to change that on msgpack site and add some english docs for your library?
http://msgpack.org/

[jippi]

bump - I'm hitting this issue under php 5.6 as well

[Sean-Der]

@jippi Hi!

Thanks for bumping this, I am working my way through the backlog. I will add a failing test for this tonight, and work on fixing this.

However, I worry that people are depending on the current broken behavior so I don't know what to do about that. @laruence opinions?

To get you up and running right now, @laruence's solution should work for you right away!

[jippi]

@Sean-Der The current behavior is quite odd, find it hard to see if anyone is actually depending on it

Alternative, implement it as a MSGPACK_SERIALIZE_ASSOC kind of flag and let it be off by default, and switch to ON at some point when you break something other? :)

Our payloads are deeply nested arrays and objects, so I would have to traverse everything by hand and forcing it to array.

Idealy for me, it would serialize to the same array structure as json_encode($object) does - that would allow for custom per-class callback for serialization etc as well - basically using https://wiki.php.net/rfc/jsonserializable :)

Our hack today is to json_encode and the msgpack it :)

[subpardaemon]

using 0.5.7-1 (remi's repo on a centos6). using msgpack as session data serialization handler (binary AND multilang, yay!) as i need the session data available in node as well. using php_only = false to be on the safe side. phpmyadmin stops working, the geniuses store entire system objects in the session (like the theme object), now stuck between a rock (phpmyadmin is needed for obvious reasons) and a hard place (php_only = false still converts objects to arrays, but i need session data in other languages).

question: if, in my application, i avoid using objects in my session data (i use assoc arrays instead), can i switch php_only = true so that phpmyadmin starts working again, yet still have the ability to use session data from php in node? in essence, is a php_only = true encoded session data usable in other languages if i keep away from storing objects in it?