-
clsMeta
ClassMetadata clsMeta
-
entityMeta
EntityMetadata entityMeta
-
priKeyField
com.sleepycat.persist.impl.FieldInfo priKeyField
-
secKeyFields
java.util.List<E> secKeyFields
-
nonKeyFields
java.util.List<E> nonKeyFields
-
secKeyFieldReader
com.sleepycat.persist.impl.ComplexFormat.FieldReader secKeyFieldReader
-
nonKeyFieldReader
com.sleepycat.persist.impl.ComplexFormat.FieldReader nonKeyFieldReader
-
oldToNewKeyMap
java.util.Map<K,V> oldToNewKeyMap
-
newToOldFieldMap
java.util.Map<K,V> newToOldFieldMap
-
evolveNeeded
boolean evolveNeeded
-
incorrectlyOrderedSecKeys
java.util.Set<E> incorrectlyOrderedSecKeys
This field contains the names of secondary keys that are incorrectly
ordered because, in an earlier version, we failed to set the dup
comparator. This bug applies only when the primary key has a
comparator. The bug was fixed by setting the dup comparator to the
primary key comparator, for all new secondary databases. [#17252]
A field containing an empty set signifies that no keys are incorrectly
ordered, while a null field signifies that all keys are incorrect (when
the primary key has a comparator). The field is assigned to an empty
set when declared, so that it will be null only when a pre-fix version
of the format is deserialized. (With Java serialization, when a field is
added to a class and a previously serialized instance is deserialized,
the new field will always be null).
This field is used to determine when a dup comparator should be set. We
cannot set the comparator for secondary databases created prior to the
bug fix, since ordering cannot be changed for existing records. See
isSecKeyIncorrectlyOrdered and setSecKeyCorrectlyOrdered.
This field does not count in comparisons of formats during evolution.
When the user wants to correct the ordering for an incorrectly ordered
secondary database, she must delete the database but does not need to
increment the class version. In other words, this is information about
the database order but is not considered class metadata.
-
newStringFormat
boolean newStringFormat
In JE 5.0 we changed the format for String fields. Instead of treating
the String as an object with a format ID embedded in the serialized
bytes, we treat it as a primitive and do not include the format ID.
This works well because a field declared to be type String cannot be
used to store any other object, and because the String tuple format
supports null values.
A field containing false signifies that the old String format was used
when the entity was written, while a true value signifies that the new
String format was used. The field is assigned to true when declared, so
that it will be false only when a pre-JE 5.0 version of the format is
deserialized. (With Java serialization, when a boolean field is added to
a class and a previously serialized instance is deserialized, the new
field will always be false).