From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- .../sleepycat/persist/evolve/package-summary.html | 565 +++++++++++---------- 1 file changed, 284 insertions(+), 281 deletions(-) (limited to 'docs/java/com/sleepycat/persist/evolve/package-summary.html') diff --git a/docs/java/com/sleepycat/persist/evolve/package-summary.html b/docs/java/com/sleepycat/persist/evolve/package-summary.html index 80dd67f8..f9df7795 100644 --- a/docs/java/com/sleepycat/persist/evolve/package-summary.html +++ b/docs/java/com/sleepycat/persist/evolve/package-summary.html @@ -1,195 +1,210 @@ - - - - - -com.sleepycat.persist.evolve (Oracle - Berkeley DB Java API) - - - - - - - - - - - - -
- - +//--> + + - - - - - - - - - - - - -
-Berkeley DB
version 5.3.21
-
- + + + + + - -
-

-Package com.sleepycat.persist.evolve -

-Utilities for managing class evolution of persistent objects. -

-See: -
-          Description -

- - - - - - - - - - - - - -
-Interface Summary
ConversionConverts an old version of an object value to conform to the current class - or field definition.
EvolveListenerThe listener interface called during eager entity evolution.
-  - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Class Summary
ConverterA mutation for converting an old version of an object value to conform to - the current class or field definition.
DeleterA mutation for deleting an entity class or field.
EntityConverterA subclass of Converter that allows specifying keys to be deleted.
EvolveConfigConfiguration properties for eager conversion of unevolved objects.
EvolveConfigBeanInfo 
EvolveEventThe event passed to the EvolveListener interface during eager entity - evolution.
EvolveInternalInternal access class that should not be used by applications.
EvolveStatsStatistics accumulated during eager entity evolution.
MutationThe base class for all mutations.
MutationsA collection of mutations for configuring class evolution.
RenamerA mutation for renaming a class or field without changing the instance or - field value.
-  - -

- - - - - - - - - - - - - -
-Exception Summary
DeletedClassExceptionWhile reading from an index, an instance of a deleted class version was - encountered.
IncompatibleClassExceptionA class has been changed incompatibly and no mutation has been configured to - handle the change or a new class version number has not been assigned.
-  - -

-

-Package com.sleepycat.persist.evolve Description -

- -

-Utilities for managing class evolution of persistent objects. +

+

Package com.sleepycat.persist.evolve

+
+
Utilities for managing class evolution of persistent objects.
+
+

See: Description

+
+
+ + + + +

Package com.sleepycat.persist.evolve Description

+
Utilities for managing class evolution of persistent objects.

Class Evolution

@@ -215,7 +230,7 @@ allowed for key fields are very limited. The only changes allowed for key fields are:

  • The name of a key field may be changed, as long as this change is -accompanied by a Renamer mutation.
  • +accompanied by a Renamer mutation.
  • A primitive type may be changed to its corresponding primitive wrapper type. This is a compatible change.
  • For primary key fields and fields of a composite key class, a primitive @@ -227,7 +242,7 @@ values. This is a compatible change.
  • Any other changes to a key field are incompatible and may be made only by performing a store conversion.

    -

    Key ordering, including the behavior of a custom Comparable, is also fixed, since keys are stored in order in the +

    Key ordering, including the behavior of a custom Comparable, is also fixed, since keys are stored in order in the index. The specifications for key ordering may not be changed, and the developer is responsible for not changing the behavior of a Comparable key class. WARNING:: Changing the behavior of a Comparable key class is likely to make the index unusable.

    @@ -250,9 +265,9 @@ compatibly; for such changes a class Converter mutation is required.

    Changes to field types in entity class definitions are compatible when they conform to the Java Language Specification definitions for Widening +href="http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2">Widening Primitive Conversions and Widening +href="http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.5">Widening Reference Conversions. For example, a smaller integer type may be changed to a larger integer type, and a reference type may be changed to one of its supertypes. Automatic widening conversions are performed @@ -285,29 +300,29 @@ new field is initialized by the default constructor.

    Incompatible changes may be handled via mutations, as described next.

    Note that whenever a class is changed, either compatibly or incompatibly, a -new (higher) class version number must be assigned. See Entity.version() and Persistent.version() for information on assigning +new (higher) class version number must be assigned. See Entity.version() and Persistent.version() for information on assigning class version numbers.

    Mutations

    -

    There are three types of mutations: Renamer, Deleter and Converter.

    +

    There are three types of mutations: Renamer, Deleter and Converter.

    -

    A class or field can be renamed using a Renamer. Renaming is not expensive, since it +

    A class or field can be renamed using a Renamer. Renaming is not expensive, since it does not involve conversion of instance data.

    -

    A class or field can be deleted using a Deleter.

    +

    A class or field can be deleted using a Deleter.

    • Deleting an entity class causes removal of the primary and secondary indices for the store, on other words, removal of all store entities for that class and its subclasses. Removal is performed when the store is opened. A -Deleter should be used for an entity class +Deleter should be used for an entity class in all of the following circumstances:
      • When removing the entity class itself.
      • -
      • When removing Entity from the class +
      • When removing Entity from the class to make it non-persistent.
      • -
      • When removing Entity from the class - and adding Persistent, to use it as an +
      • When removing Entity from the class + and adding Persistent, to use it as an embedded persistent class but not an entity class. The version of the class must be incremented in this case.
      @@ -316,15 +331,15 @@ in all of the following circumstances:
    • Deleting a non-entity class does not itself cause deletion of instance data, but is needed to inform DPL that the deleted class will not be used. Instances of the deleted class must be handled (discarded or converted to -another class) by Deleter or Converter mutations for the field or enclosing -class that contain embedded instances of the deleted class. A Deleter should be used for a non-entity class in +another class) by Deleter or Converter mutations for the field or enclosing +class that contain embedded instances of the deleted class. A Deleter should be used for a non-entity class in all of the following circumstances:
      • When removing the persistent class itself.
      • -
      • When removing Persistent from the +
      • When removing Persistent from the class to make it non-persistent.
      • -
      • When removing Persistent from the - class and adding Entity, to use it as an +
      • When removing Persistent from the + class and adding Entity, to use it as an entity class but not an embedded persistent class. The version of the class must be incremented in this case.
      @@ -334,13 +349,13 @@ all of the following circumstances: that field, in order to discard the field values.
    -

    Other incompatible changes are handled by creating a Converter mutation and implementing a Conversion.convert method that +

    Other incompatible changes are handled by creating a Converter mutation and implementing a Conversion.convert method that manipulates the raw objects and/or simple values directly. The convert method is passed an object of the old incompatible type and it returns an object of a current type.

    Conversions can be specified in two ways: for specific fields or for all -instances of a class. A different Converter constructor is used in each case. +instances of a class. A different Converter constructor is used in each case. Field-specific conversions are used instead of class conversions when both are applicable.

    @@ -359,7 +374,7 @@ the data or type information. changes may reuse a given name for more than one version. To identify the specific type being converted or renamed, a version number is needed. -

    See Entity.version() and Persistent.version() for information on assigning +

    See Entity.version() and Persistent.version() for information on assigning class version numbers.

    Mutations are therefore responsible for converting each existing @@ -371,9 +386,9 @@ converter for A-1 will have to be changed. Instead of converting from A-1 to A-2 it will need to convert from A-1 to A-3. In addition, a mutation converting A-2 to A-3 will be needed.

    -

    When a Converter mutation applies to a +

    When a Converter mutation applies to a given object, other mutations that may apply to that object are not -automatically performed. It is the responsibility of the Converter to return an object that conforms to +automatically performed. It is the responsibility of the Converter to return an object that conforms to the current class definition, including renaming fields and classes. If the input object has nested objects or superclasses that also need conversion, the converter must perform these nested conversions before returning the final @@ -381,7 +396,7 @@ converted object. This rule avoids the complexity and potential errors that could result if a converter mutation were automatically combined with other mutations in an arbitrary manner.

    -

    The EntityStore.evolve +

    The EntityStore.evolve method may optionally be used to ensure that all instances of an old class version are converted to the current version.

    @@ -391,37 +406,37 @@ version are converted to the current version.

    entity class. When a field that happens to be a primary or secondary key field is renamed, its metadata remains intact as well.

    -

    When the SecondaryKey annotation is +

    When the SecondaryKey annotation is added to an existing field, a new index is created automatically. The new index will be populated by reading the entire primary index when the primary index is opened.

    -

    When the SecondaryKey annotation is +

    When the SecondaryKey annotation is included with a new field, a new index is created automatically. The new field is required to be a reference type (not a primitive) and must be initialized to null (the default behavior) in the default constructor. Entities will be indexed by the field when they are stored with a non-null key value.

    -

    When a field with the SecondaryKey -annotation is deleted, or when the SecondaryKey annotation is removed from a field +

    When a field with the SecondaryKey +annotation is deleted, or when the SecondaryKey annotation is removed from a field without deleting it, the secondary index is removed (dropped). Removal occurs when the store is opened.

    -

    The SecondaryKey.relate property may NOT be changed. All other properties of a -SecondaryKey may be changed, although +

    The SecondaryKey.relate property may NOT be changed. All other properties of a +SecondaryKey may be changed, although avoiding changes that cause foreign key integrity errors is the responsibility -of the application developer. For example, if the SecondaryKey.relatedEntity() property is added but +of the application developer. For example, if the SecondaryKey.relatedEntity() property is added but not all existing secondary keys reference existing primary keys for the related entity, foreign key integrity errors may occur.

    -

    The PrimaryKey annotation may NOT be +

    The PrimaryKey annotation may NOT be removed from a field in an entity class.

    -

    The PrimaryKey.sequence() property may be +

    The PrimaryKey.sequence() property may be added, removed, or changed to a different name.

    -

    The Persistent.proxyFor() property may NOT +

    The Persistent.proxyFor() property may NOT be added, removed, or changed to a different class.

    Warnings on Testing and Backups

    @@ -460,86 +475,74 @@ combining two separate entity classes into a new single entity class. following steps to copy the data from the old store to a new converted store:

      -
    1. The old store is opened as a RawStore and -the new store is opened as an EntityStore.
    2. -
    3. All entities are read from the old store. Entities are read using a RawStore to allow access to entities for which no +
    4. The old store is opened as a RawStore and +the new store is opened as an EntityStore.
    5. +
    6. All entities are read from the old store. Entities are read using a RawStore to allow access to entities for which no compatible class exists.
    7. -
    8. The RawObject entities are then converted +
    9. The RawObject entities are then converted to the format desired. Raw objects can be arbitrarily manipulated as needed. The updated raw objects must conform to the new evolved class definitions.
    10. The updated raw entities are converted to live objects by calling the -EntityModel.convertRawObject method of the new store. This method converts +EntityModel.convertRawObject method of the new store. This method converts raw objects obtained from a different store, as long as they conform to the new evolved class definitions.
    11. -
    12. The new live objects are written to the new EntityStore using a PrimaryIndex as usual.
    13. +
    14. The new live objects are written to the new EntityStore using a PrimaryIndex as usual.

    To perform such a conversion, two separate stores must be open at once. -Both stores may be in the same Environment, if +Both stores may be in the same Environment, if desired, by giving them different store names. But since all data is being rewritten, there are performance advantages to creating the new store in a new fresh environment: the data will be compacted as it is written, and the old store can be removed very quickly by deleting the old environment directory -after the conversion is complete.

    -

    - -

    -

    -
    -
    - - +after the conversion is complete.

+
- - - - - - - - - - - - -
-Berkeley DB
version 5.3.21
-
- + + + + + - -
-Copyright (c) 1996, 2012 Oracle and/or its affiliates. All rights reserved. - - +

Copyright (c) 1996, 2015 Oracle and/or its affiliates. All rights reserved.

+ + -- cgit v1.2.1