Re: Gorm - error when saving previous version (Gworkspace)

[Fred Kiefer]

On 20.05.2012 00:49, Riccardo Mottola wrote:
> Hi All,
>
> On 05/14/12 15:47, Riccardo Mottola wrote:
> > Hi,
> >
> > I need to save a gworkspace gorm file (DesktopPrefs) with a version
> > previous to current. Gorm gives the opportunity to select 0.10.3 (what
> > version does this refer to? Should we add a newer one?)
> >
> > I can save it and reopen it. However if I reopen it with "really" a
> > previous release (in this case our last release, base 1.24 and gui
> > 0.22) it won't open, vingi an int vs. unsigned int exception
> >
> > I think our we have a compatibility problem with the encoded archive.
> > Can that be fixed? Thank you.
> can we work on this? It is not only a nasty bug (we should for
> convenience always be able to save a correct version, else the version
> feature in Gorm is useless and deceiving) but it is also blocking a good
> and long needed release of gworkspace.
>
> Gregory says it is not a Gorm problem but a gui/base compatibility
> archiving problem.
>
> How can I help identifying what got incompatible so it can be fixed?

Hi Riccardo,

I looked into your problem more deeply and there were two issues 
blocking you. One was the change Richard made in the way we store the 
item count of an array in archives. Richard improved on that an now 
archives store this count in a forward compatible way in most cases, 
this means old code will be able to read arrays in archives written by 
newer code.
The other issues hasn't been resolved and is unlikely to get resolved. 
In the last release we changed the way some classes get archived. This 
has happened for almost all gui releases over the last years and there 
isn't much we can do about it. We try to implement the new archiving 
code in a way that allows us to read old archives, but there is no way 
to allow old code to read newer archives, when the format changes.
Now the simplest solution for you would be to switch over to keyed 
archives, in this case from Gorm to NIB files. This format is backward 
and forward compatible most of the time and for this reason should be 
preferred over non-keyed archives.
If this isn't an option for you, your could try to build a hybrid 
version of archiving for the classes that are needed for you specific 
Gorm files. That is, you move the -encodeWithCoder: back to the last 
version and keep the -initWithCoder: method on the new state. This 
requires that you find all the classes where this is needed and is is 
also a bit dangerous, as you will write out the objects with the wrong 
version number if you don't change that number as well.
If you are very sure that your only problem are the unsigned/signed 
changes that Sebastian made a while ago, then there is another option, 
you could remove the sign check from the base code, or rather make it a 
warning. (This is in NSUnarchiver.m in the function typeCheck) This may 
even be a change we could keep. But don't expect this to resolve all 
your issues with forward compatibility. For example NSTableColumn and 
NSTextView were also changed in a incompatible way. If I remember 
correctly, this was to fix bugs that you reported.

Fred