[Rd] modifying a persistent (reference) class

[Ross Boylan]

On Fri, 2014-08-01 at 14:42 -0400, Brian Lee Yung Rowe wrote:
> Ross,
> 
> 
> This is generally a hard problem in software systems. The only
> language I know that explicitly addresses it is Erlang. Ultimately you
> need a system upgrade process, which defines how to update the data in
> your system to match a new version of the system. You could do this by
> writing a script that 
> 1) loads the old version of your library
> 2) loads your data/serialized reference classes
> 3) exports data to some intermediate format (eg a list)
> 4) loads new version of library
> 5) imports data from intermediate format
My recollection is that in Gemstone's smalltalk database you can define
methods associated with a class that describe how to change an instance
from one version to another.  You also have the choice of upgrading all
persistent objects at once or doing so lazily, i.e., as they are
retrieved.

The brittleness of the representation depends partly on the details.  If
a class has 2 slots, a and b, and the only thing on disk is the contents
of a and the contents of b, almost any change will screw things up.
However, if the slot name is persisted with the instance it's much
easier to reconstruct the instance of the class changes (if slot c is
added and not on disk, set it to nil; if b is removed, throw it out when
reading from disk).  Once could also persist the class definition, or
key elements of it, with individual instances referring to the
definition.

I don't know which, if any of these strategies, R uses for reference or
other classes.
> 
> 
> Once you've gone through the upgrade process, arguably it's better to
> persist the data in a format that is decoupled from your objects since
> then future upgrades would simply be
> 1) load new library
> 2) import data from intermediate format
Arguably :)  As I said, some representations could do this
automatically.  And there are still issues such as a change in the type
of a slot, or rules for filling new slots, that would require
intervention.

In my experience with other object systems, usually methods are
attributes of the class.  For R reference classes they appear to be
attributes of the instance, potentially modifiable on a per-instance
basis.

Ross
> 
> 
> which is no different from day-to-day operation of your app/system (ie
> you're always writing to and reading from the intermediate format). 
> 
> 
> Warm regards,
> Brian
> 
> •••••
> Brian Lee Yung Rowe
> Founder, Zato Novo
> Professor, M.S. Data Analytics, CUNY
> 
> On Aug 1, 2014, at 1:54 PM, Ross Boylan <ross at biostat.ucsf.edu> wrote:
> 
> 
> > I saved objects that were defined using several reference classes.
> > Later I modified the definition of reference classes a bit, creating
> > new
> > functions and deleting old ones.  The total number of functions did
> > not
> > change.  When I read them back I could only access some of the
> > original
> > data.
> > 
> > I asked on the user list and someone suggested sticking with the old
> > class definitions, creating new classes, reading in the old data,
> > and
> > converting it to the new classes.  This would be awkward (I want the
> > "new" classes to have the same name as the "old" ones), and I can
> > probably just leave the old definitions and define the new functions
> > I
> > need outside of the reference classes.
> > 
> > Are there any better alternatives?
> > 
> > On reflection, it's a little surprising that changing the code for a
> > reference class makes any difference to an existing instance, since
> > all
> > the function definitions seem to be attached to the instance.  One
> > problem I've had in the past was precisely that redefining a method
> > in a
> > reference class did not change the behavior of existing instances.
> >  So
> > I've tried to follow the advice to keep the methods light-weight.
> > 
> > In this case I was trying to move from a show method (that just
> > printed)
> > to a summary method that returned a summary object.  So I wanted to
> > add
> > a summary method and redefine the show to call summary in the base
> > class, removing all the subclass definitions of show.
> > 
> > Regular S4 classes are obviously not as sensitive since they usually
> > don't include the functions that operate on them, but I suppose if
> > you
> > changed the slots you'd be in similar trouble.
> > 
> > Some systems keep track of versions of class definitions and allow
> > one
> > to write code to migrate old to new forms automatically when the
> > data
> > are read in.  Does R have anything like that?
> > 
> > The system on which I encountered the problems was running R 2.15.
> > 
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >