Versioning and persistence

[Patrick Logan]

>>>>> "Scott" == Scott L Burson <gyro@zeta-soft.com> writes:

    From: Patrick Logan <patrickl@servio.gemstone.com> Date:
    Tue, 20 May 97 17:16 PDT

    > In Gemstone each "session" essentially has its own "object
    > table" tied to the state of the world when it began its current
    > transaction. It is impossible to access one object from one
    > "version" and another object from another "version". That would
    > be illogical.

    Scott> That certainly simplifies things, but seems to me that it's
    Scott> important to be able to compare different versions of
    Scott> stuff, if a way can be found to make it work.

Gemstone supports simultaneous versions of classes. This is "above"
the level of the repository. All versions are in the repository as
disctinct objects and related by another distinct object called a
version history.

Instance of each of these versions can all exist simultaneously, and
can be migrated to newer versions en masse or individually with all
sorts of conversion options. Instance of older versions are not
entirely given their due respect though, since some objects in the
system always refer to the latest version of a class. For example the
B-tree indexing mechanism on a collection always refers to the latest
version, although technically it shouldn't have to. (And since I am
rewriting it this year, I will pay more attention to that. 8^)

The session can read and write any of the instances of any version of
any class that it has permissions for. The session's "image" contains
all the instances and class versions that are in the repository.

-- 
Patrick Logan                 mailto:patrickl@gemstone.com
Voice 503-533-3365            Fax   503-629-8556
Gemstone Systems, Inc         http://www.gemstone.com