I've serialized an object with Fuel and can't get it back in another image:
Could not find a serializer with id=0 in FLCluster class>>forId: The instance variable 'serializersById' contains a dictionary with other integers than 0 for its keys (1, 2, 3, 4, 7, etc). Is it a known problem, something I'm doing wrong? Maybe because I've serialized an object from Pharo 1.2 to 1.3? Cheers, Fa |
Hi Francois.
Can you reproduce the problem? If true, please let us know how. Mariano On Sun, Jul 3, 2011 at 8:30 PM, Francois Stephany <[hidden email]> wrote: I've serialized an object with Fuel and can't get it back in another image: -- Mariano http://marianopeck.wordpress.com |
Hi Mariano,
I'll try to nail down the problem. Any hint on what can cause the problem? I'm probably doing something stupid... On 03/07/11 20:43, Mariano Martinez Peck wrote: > Hi Francois. > > Can you reproduce the problem? If true, please let us know how. > > Mariano > > On Sun, Jul 3, 2011 at 8:30 PM, Francois Stephany > <[hidden email] <mailto:[hidden email]>> wrote: > > I've serialized an object with Fuel and can't get it back in another > image: > > Could not find a serializer with id=0 in FLCluster class>>forId: > > The instance variable 'serializersById' contains a dictionary with > other integers than 0 for its keys (1, 2, 3, 4, 7, etc). > > Is it a known problem, something I'm doing wrong? Maybe because I've > serialized an object from Pharo 1.2 to 1.3? > > Cheers, > Fa > > > > > -- > Mariano > http://marianopeck.wordpress.com > |
On Sun, Jul 3, 2011 at 9:00 PM, Francois Stephany <[hidden email]> wrote: Hi Mariano, Excellent. Any hint on what can cause the problem? Not really. The problem seems to be that the file was not correctly written. Objects are grouped in clusters. So we write the id of the cluster, then the amount of objects of such clusters and finally we write those objects. At materialization, we read the data. In this case, it seems we are reading something different from expected, so we do something like clusterId := stream readInteger to get the id but in fact we are getting a zero, because we are actually reading something different from expected. Can you see if evaluating "FuelUtilities cleanUpEverything" helps ? Which version of the package FUel are you using ? How did you exactly installed Fuel ? I'm probably doing something stupid... Not sure. Can you also tell us how did you serialize/materialize? which kind of object you were trying to serialize? thanks
-- Mariano http://marianopeck.wordpress.com |
Do you have differnt versions of Fuel in the two differnt images ?
On Sun, Jul 3, 2011 at 9:28 PM, Mariano Martinez Peck <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
> Do you have differnt versions of Fuel in the two differnt images ? That was it. One image had latestVersion (which is 1.4) and the other 1.5 (blessed as 'development'). Thanks ! |
On Sun, Jul 3, 2011 at 10:23 PM, Francois Stephany <[hidden email]> wrote:
Excellent. One image had latestVersion (which is 1.4) and the other 1.5 (blessed as 'development'). Yes, but this is a problem. We should throw a nice error explaining the situation instead of that. In fact, we are serializing a "version" of Fuel and we should raise an error in such case. So I am not sure why you received that. Martin? Thanks ! -- Mariano http://marianopeck.wordpress.com |
indeed :)
this scenario should work. > > That was it. > > Excellent. > > One image had latestVersion (which is 1.4) and the other 1.5 (blessed as 'development'). > > > Yes, but this is a problem. We should throw a nice error explaining the situation instead of that. In fact, we are serializing a "version" of Fuel and we should raise an error in such case. So I am not sure why you received that. > Martin? > > Thanks ! > > > > > -- > Mariano > http://marianopeck.wordpress.com > |
In reply to this post by Mariano Martinez Peck
Yes, we have to work on it.
I think version handling should be added wrapping the basic serializer, like other features like a checksum, compression, or encryption. So the class that serializes just worries about serialization. For example, in the Moose extension we are signing the stream with this prefix: 'FLMoose', version where version represents a two-byte integer. A kind of façade adds this behavior in FLMooseContainerWriter and FLMooseContainerReader, throwing error when either stream doesn't begin with 'FLMoose', or it is a different version. Implementation of FLMooseContainerWriter and FLMooseContainerReader are questionable, but my point is that I believe version is a meta-information about the stream that can be appended optionally. Do you agree? Martin On Sun, Jul 3, 2011 at 6:08 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |