Browsing French translation

1712.

<code class="python">self.upgradeToVersion1()</code> would be called, changing <code>self.size</code> into a string, like <q>5 inches</q>.

1713.

<code class="python">self.upgradeToVersion2()</code> would be called, changing <code>self.size</code> into a tuple, like (5, <q>inches</q>).

1714.

Finally, <code class="python">self.upgradeToVersion3()</code> would be called, creating <code>self.size</code> as a list holding a single dimension, like [(5, <q>inches</q>)]. The old <code>.length</code> attribute is deleted, and a new <code>.name</code> is created with the type of shape this instance represents (<q>line</q>).

1715.

Some hints for the <code>upgradeVersion</code> methods:

1716.

They must do everything the <code>__init__</code> method would have done, as well as any methods that might have been called during the lifetime of the object.

1717.

If the class has (or used to have) methods which can add attributes that weren't created in <code>__init__</code>, then the saved object may have a haphazard subset of those attributes, depending upon which methods were called. The upgradeVersion methods must be prepared to deal with this. <code>hasattr</code> and <code>.get</code> may be useful.

1718.

Once you have released a class with a given <code>upgradeVersion</code> method, you should never change that method. (assuming you care about infinite backwards compatibility).

1719.

You must add a new <code>upgradeVersion</code> method (and bump the persistenceVersion value) for each and every release that has a different set of data attributes than the previous release.

1720.

<code>Versioned</code> works by providing <code>__setstate__</code> and <code>__getstate__</code> methods. You probably don't want to override these methods without being very careful to call the Versioned versions at exactly the right time. It also requires a <code>doUpgrade</code> function to be called after all the objects are loaded. This is done automatically by <code>Application.run</code>.

1721.

Depending upon how they are serialized, <code>Versioned</code> objects can probably be sent across a network connection, and the upgrade process can be made to occur upon receipt. (You'll want to look at the <code class="API" base="twisted.persisted.styles">requireUpgrade</code> function). This might be useful in providing compability with an older peer. Note, however, that <code>Versioned</code> does not let you go backwards in time; there is no <code>downgradeVersionNN</code> method. This means it is probably only useful for compatibility in one direction: the newer-to-older direction must still be explicitly handled by the application.