[Pharo-project] I am serializing correctly with SIXX?

Mariano Martinez Peck marianopeck at gmail.com
Thu Jun 2 10:02:44 EDT 2011


Yes Igor. You are correct. We should pass the info we have stored in the
serialization so that they can initialize correctly :)

On Thu, Jun 2, 2011 at 3:42 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 2 June 2011 15:22, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> >
> >
> > On Thu, Jun 2, 2011 at 3:00 PM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> Btw, what deserializer does, if it discovers that instance of some
> >> class, which you want to bring to life from storage
> >> now has its format changed?
> >> suppose that when saving graph, some class has inst vars 'a b c'
> >> but then you changed the class definition and its inst vars now 'a d e'
> >> ?
> >
> > In this, Fuel will materialize the object, set the instVar 'a' and 'd'
> and
> > 'e' will be with nil.
> > After, the user of FUel can do whatever he wants.
> > In fact, we will provide soemthing like #initializeFromFuel  or something
> > like that that is automatically called by Fuel after the materialization.
> > We throw error where there is something we cannot do.
> >
>
> Well, then it should be
> initializeFromFuel: fuelSpec
>
> instead of just
> initializeFromFuel
>
> because if you don't know, what were stored in fuel stream, you cannot
> properly migrate the instance.
> Consider that initially class has inst vars 'a'
> and you saved this instance to fuel.
> Then you changed ivars to 'a b'
> and changed the #initializeFromFuel appropriately.
> But then you again changed ivars to 'c b d'
> and also changed #initializeFromFuel
> Now if you attempt to materialize the instance from first version
> (with only 'a'),
> you cannot determine what original format of instance were stored in fuel,
> and so, you cannot decide what will be a proper migration path:
> 'a' -> 'c b d'
> or
> 'a b' -> 'c b d'
> or
> 'c b d' -> 'c b d'
>
> and i think it is better to move this method to class side, then it
> can deal with migration before creating an instance.
> So you can even replace an instance of original class with something
> else (if you refactored your model and no longer want
> an instances of old class, so you stub a creation of them in class
> side of old class, and create instances of different class instead).
>
> Or even two-phase materialization:
>
> SomeClass class>>materializeFromFuel: fuelSpec
>   ... "some common logic" ..
>  ^ self basicNew initializeFromFuel: fuelSpec
>
> so, you will have two polymorphic entry points.
>
> >>
> >> I think it is not a responsibility of serializer to deal with that
> >> (there should be a higher level layer which can handle instance
> >> migration),
> >> while serializer just reports an error that it can't reify an object
> >> because its original class are either gone or changed format.
> >
> > yes, but there are things that we can do (kind of first pass) so that we
> can
> > give the user the object already mterialized and he can update it.
> >
> > In fuel, we have these tests:
> >
> >
> > testVariableInsertion
> >     "Tests that serializer tolarates when there is a new instance
> variable
> > on materialization"
> >
> >     | stream aPair resultPair |
> >
> >     aPair := (self stubClassWithInstanceVars: 'left right') new.
> >     aPair instVarAt: 1 put: $A.
> >     aPair instVarAt: 2 put: $B.
> >     stream := self serializationOf: aPair.
> >
> >     self stubClassWithInstanceVars: 'left middle right'.
> >     resultPair := self materializationOn: stream reset.
> >     self assert: $A equals: (resultPair instVarAt: 1).
> >     self assert: nil equals: (resultPair instVarAt: 2).
> >     self assert: $B equals: (resultPair instVarAt: 3).
> >
> >
> >
> > testVariableRemoved
> >     "Tests that serializer tolarates when an instance variable is missing
> on
> > materialization"
> >
> >     | stream aPair resultPair |
> >
> >     aPair := (self stubClassWithInstanceVars: 'left right') new.
> >     aPair instVarAt: 1 put: $A.
> >     aPair instVarAt: 2 put: $B.
> >     stream := self serializationOf: aPair.
> >
> >     self stubClassWithInstanceVars: 'right'.
> >     resultPair := self materializationOn: stream reset.
> >     self assert: $B equals: (resultPair instVarAt: 1).
> >
> >
> >
> > testVariableOrderChange
> >     "Tests that serializer tolarates when the order in the instance
> > variables changed between serialization and materialization"
> >
> >     | pairClass stream aPair resultPair |
> >
> >     pairClass := self stubClassWithInstanceVars: 'left right'.
> >     aPair := pairClass new.
> >     aPair instVarAt: 1 put: $A.
> >     aPair instVarAt: 2 put: $B.
> >     stream := self serializationOf: aPair.
> >
> >     pairClass := self stubClassWithInstanceVars: 'right left'.
> >     resultPair := self materializationOn: stream reset.
> >     self assert: $B equals: (resultPair instVarAt: 1).
> >     self assert: $A equals: (resultPair instVarAt: 2).
> >
> >
> >
> >
> >
> >>
> >> On 2 June 2011 14:51, Norbert Hartl <norbert at hartl.name> wrote:
> >> >
> >> > Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck:
> >> >
> >> > Thanks Norbert. Now I could successfully run benchmarks for SIXX and
> >> > compare
> >> > with Fuel. But that's not really fare because we are comparing a text
> >> > based
> >> > serializer against a binary one.
> >> >
> >> > It is interesting anyway. I like to know if it is 20 times faster or
> >> > even
> >> > more. On the other hand it is not fair either. I don't know fuel but I
> >> > think
> >> > it platform dependent, right? So it is not fair the other way round
> >> > because
> >> > you compare a cross-platform serializer with a platform-dependent one
> ;)
> >> > I
> >> > think these are the categories that people think about when the are
> >> > about to
> >> > choose what util to use.
> >> > Norbert
> >> >
> >> > Mariano
> >> >
> >> > On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert at hartl.name>
> >> > wrote:
> >> >>
> >> >> Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck:
> >> >>
> >> >> >> serialize: anObject on: aStream
> >> >>     | sws |
> >> >>     sws := SixxWriteStream on: aStream.
> >> >>     sws nextPut: anObject.
> >> >>     sws close.
> >> >>
> >> >> serialize: anObject on: aStream
> >> >>    anObject sixxOn: aStream
> >> >>
> >> >> >> materializeFrom: aStream
> >> >>     | srs objects |
> >> >>     srs := SixxReadStream on: aStream.
> >> >>     objects := srs contents.
> >> >>     srs close.
> >> >>     ^ objects
> >> >>
> >> >> materializeFrom: aStream
> >> >> ^ Object readSixxFrom: aStream
> >> >> Norbert
> >> >>
> >> >>
> >> >>
> >> >> Is that correct or I am doing it wrong?  All I want to do is to
> >> >> serialize
> >> >> a graph into a stream.
> >> >>
> >> >> The stream I am using is or this:
> >> >>
> >> >> (FileDirectory default forceNewFileNamed:  'Bench')
> >> >>
> >> >> or
> >> >>
> >> >> (RWBinaryOrTextStream on: '')
> >> >>
> >> >>
> >> >> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I
> >> >> mean,
> >> >> sometimes anObject is a collection and sometimes it is not. So, which
> >> >> one
> >> >> should I use?
> >> >>
> >> >> Thanks
> >> >>
> >> >> Mariano
> >> >>
> >> >>
> >> >> --
> >> >> Mariano
> >> >> http://marianopeck.wordpress.com
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Mariano
> >> > http://marianopeck.wordpress.com
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko AKA sig.
> >>
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20110602/03dd4fd7/attachment-0001.html>


More information about the Pharo-dev mailing list