Question about Marshal.dump behavior

I had gotten the impression that the third parameter to Marshal.dump acted
as a limit on the depth of the serialization. One could use it to
deliberately exclude data from serialization if it was stored in nested
objects below a certain level.

But I’ve run into some behavior that suggests that to use this parameter you
have to know the complete depth of the target object; passing a number lower
than that depth raises an exception.

Here is some example code:

···

#----------------------------
class LimitTest
def initialize( x )
@stuff = x
end
end

lt = LimitTest.new( “a” )
mdata = Marshal.dump(lt, 2 ) #OK

lt = LimitTest.new( [“b”, “c”])
mdata = Marshal.dump(lt, 2 ) # Error

`dump’: exceed depth limit (ArgumentError)

#----------------------------

This happens with ruby 1.6.7 (2002-03-01) [i586-mswin32],
ruby 1.7.2 (2002-06-29) [i386-mswin32], and ruby 1.7.2 (2002-05-02)
[i586-linux]

Is this behavior correct? It seems the calling code has to know the depth
of the object and any references it has, and is compelled to serialize the
entire object. Can one tell Marshal.dump to ignore objects below a certain
depth (without writing your own _dump)?

Thanks,

James

Hi,

···

In message “Question about Marshal.dump behavior” on 02/08/06, " JamesBritt" james@jamesbritt.com writes:

I had gotten the impression that the third parameter to Marshal.dump acted
as a limit on the depth of the serialization. One could use it to
deliberately exclude data from serialization if it was stored in nested
objects below a certain level.

But I’ve run into some behavior that suggests that to use this parameter you
have to know the complete depth of the target object; passing a number lower
than that depth raises an exception.

Is this behavior correct? It seems the calling code has to know the depth
of the object and any references it has, and is compelled to serialize the
entire object. Can one tell Marshal.dump to ignore objects below a certain
depth (without writing your own _dump)?

Yes. It’s to avoid (almost) inifinite dump loop. I didn’t want
“dump” to dump incomplete object. If someone come up with a better
idea, I’d like to hear.

						matz.

Yes. It’s to avoid (almost) inifinite dump loop. I didn’t want
“dump” to dump incomplete object. If someone come up with a better
idea, I’d like to hear.

Oh, OK; so, code to pass an expected value for the object depth, and if dump
blows up, the app can decide (for example) if it should be retry the call
with no limit, or do something else because the object is deeper than
expected (and so all bets are off).

To provide for partial serialization, then, I would have to write my own
_dump method and logic for what to do if the depth limit is greater than the
actual object depth.

Thanks,

James

···
  					matz.