Chapter 4 PersistenceCapable
In JDO, all custom lasting classes must implement a javax.jdo.spi.PersistenceCapable interface. This interface contains some complex methods to make JDOs to manage the persistence of class instances. Fortunately, you don't have to realize yourself This interface, in fact, writing a long-lasting class and writing ordinary classes. There is no separate. No special classes require inheritance, do not have to use special field types, no need to write special methods. This is also JDO to make persistence to developers Important reflection of "transparency".
4.1 JDO Enhancers In order to make you free from the wrong PersistenceCapable interface, many JDO implemenical features provide a tool called "Enhancer". Enhancers are a tool: you write a persistent class, then enhance The person will automatically increase the code to your class. Although some vendors will modify your Java code with source code, it is usually, and the enhancer is mainly in the .class file. Java compiler compiles your file, Generate byte codes, enhanced these code. Add some necessary fields and methods to implement the persistencecapable interface. The modified Java byte code is perfectly reserved in the stack order and is fully compatible with the Java debugger. So enhanced operations Does not affect debugging.
The above figure depicts a compilation process of a persistence class. Typical JDO implementation will contain an Ant enhancement Task, so you can use the enhanced role as part of the compilation, automatically.
All JDO enhancers are required to do one another byte. This means that the "enhanced" class can not only be used to enhance the JDO implementation of this class, but can be used for all other JDO implementations. Byte compatible Features require that you can distribute it to other developers after packaging your lasting class, and don't worry that they are using the JDO implementation provided by which vendors. This means that you choose a manufacturer's JDO, don't Rebate your lasting class.
4.2 Compare "Oversmissible" and "Suid" enhanced implementation of the PersistenceCapable interface class can be "can last for". Direct access to the PUBLIC or PROTECTED PERF field of persistent classes is called "the lasting "The lasting class must also" enhance "- each time the lasting class is directly accessed for a long-term persistent field, the enhancer increases some code, inform the JDO to implement the field being accessed, will be read Or write. This allows the JDO to achieve the value of the product according to the needs of the data. Unless the lasting class is also a long-lasting class, the reinforcer does not increase the code to make the PersistenceCapable interface.
Usually, in addition to the standard parameters facilitating the package status, it is best to make all your lasting fields are public, if it is protected, guarantees that they are only lasting subclasses. This avoids this situation: When non-persistent class access Which non-persistent class should be enhanced as "this lasting" when you have a footprint.
4.3. Limitation of lasting class
There is only little constraints using long-lasting classes. Moreover, these constraints do not affect you familiar with JDO, what is it supported and what does not support.
4.3.1. Default Non-Part Conformal Content Function
The JDO specification requires all long-lasting classes must have a non-arranging constructor, and must be a private type. If necessary, the compiler will automatically manufacture the default non-arranging constructor when there is no other constructor. If the class defines the constructor, you must provide a PRIVATE-free constructor.
4.3.2. Inheritance
JDO fully supports the sustainable inheritance mechanism. Sustainable classes can inherit from non-persistent classes, non-lasting classes can inherit sustainable classes, and even generate a long-lasting inheritance hierarchy (?), However, some important limits must pay attention to: The lasting class cannot inherit some classes implemented by the local system, such as java.net.socket and java.lang.thread. If the lasting class inherits the non-persistent class, the non-persistent class cannot be persisted. All inherited the tree Categories must use the same JDO identification type. If they use the same application ID, they must also use the same identity class. Or they must declare their separated class, these types of inheritance hierarchical (for example, abstract) The inheritance of the lasting class must be accurately mapped. Soon we will discuss the JDO logo.
JDO manages the status of all persistent fields. Before accessing the field, JDO guarantees that it has been read from the data store. When you set a field value, JDO will record it has changed, making the new value lasting. This feature makes you The persistence field can be seen as any other field. This is also another aspect of JDO "transparent persistence". JDO supports many most common types, these types can be roughly divided into three categories: constant type, variable Types and relationships. Unless the new value of the field is re-specified, the value of the constant type remains unchanged. JDO supports the following types as a persistent field:
All basic types (int, float, byte, etc)
All basic types of packaging classes (java.lang.integer, java.lang.float, java.lang.byte, etc)
Java.lang.string java.math.biginteger java.math.bigdecimal java.lang.Number java.util.locale
There is no need to specify a new value, the value of the variable type persistent field can be changed. Variable types can be directly modified by themselves. JDO specification requires JDO to support the following variable field type java.util.date java.util.hashset
Many JDO implemenines do not allow you to last in a variable type of variable types. For example, the date is a Hashset type.
Kodo JDO supports the following variable types: java.util.date java.util.list java.util.arraylist java.util.LinkedList java.util.util.util.set java.util.hashset java.util.hashset Java.util.Sortedset Java .util.treeeset java.util.map java.util.hashmap java.util.treeMap java.util.treemap java.util.hashtable java.util.properties
The JDO implementation has transparently supports variable fields, which replaces the value of the field with a field defined subclass instance. For example, if your persistence object contains a field, the value of the field contains java.util.date type, JDO implementation The subclass of the DATE class provided by the manufacturer is replaced by the date of the DATE class, which can be called JDODATE. This jdodate subclass is to track the modification of the field to overload all Date. Change the method, notifying the value of the JDO field has been changed. Next, JDO will write a new value of the field to the database. Of course, these mechanisms are transparent when you develop and use sustainable classes. You are like habits Write a variable type method. However, understanding how JDO supports variable type mechanism is important so you can understand why JDO is particularly tricky when the array is handled. Jdo runs you using arrays as a field, as an array When the value changes, it automatically checks when these fields are assigned or set to null. However, JDO cannot check the assignment of the array index because the array has no subclasses. If you set a persistent array index, then you must Reset the value of the array, or clearly telling JDO you changed the value of the array. This is called a "stain" field. "Stroke" will be completed by the JDoHelper's MakeDirty method. (This is not very good here, especially the array index There)
As the parent-child example described above, in addition to supporting the currently mentioned Java type, JDO also supports the relationship between persistent objects. All JDO implementation should support custom lasting and custom lasting collections The type of sustainable field. The collection class can save a sustained relationship, depending on which type variable field type supported by the JDO implementation. Some JDO implementations will support the keywords, values, or both of the MAP type fields and other Persistent objects have a relationship. Most JDO implementations also support those fields that do not know the specific types. For example, a field that is java.lang.object or custom interface type. Since these fields are so common, use them. For example, They cannot be queried, and the efficiency is less efficient when loading and sorting.
Note: KODO JDO supports a custom-operable object as an element that is supported collection type. And supports it as any supported MAP type keyword and value. Kodo JDO Values through the serialization field and as a series of byte codes Sort by supporting the sustainableness of the java.lang.object type field. And supports the segment of the interface field. It is arranged in the unique identifier of the object stored in the field. When the field is loaded, it retrieves the corresponding object. Elements of the collection and MAP types can be java.lang.object or interface type. 4.3.4. Conclusion
This section detailed the JDO restrictions on sustainable classes. It seems that there are many information. In fact, when you develop, you rarely come into these restrictions. Plus, by using the other features of JDO, you can Open these restrictions. The next section will introduce some powerful features of JDO to achieve this.
4.4 Example review
Your sustainable class can implement a javax.jdo.instanceCallbacks interface, so you can get rollback in some JDO lifecycle events. This interface consists of the following four methods:
1) JDOPSTLOAD method: After you read the field group from the data store, the JDO implementation will call the JDopostLoad method. The default take-up group will introduce in the JDO Metadata section. Temporarily, you can take the default to remove the group imagination All basic fields of the object. In this method, other persistence fields cannot be accessed. JDopostLoad is usually used to assign a non-persistent field. These non-persistent fields are values depend on the persistence field. The examples are provided below.
2) Call the JDOPRESTORE method before the object's persistence value is stored in the database. In this method you can access all persistence fields. JdopRestore is complementary to JDopostLoad. JdopostLoad is usually used to initialize non-persistent values from the persistence data. JDOPRESTORE sets the value of a non-persistent field to the persistence field.
3) JDopreclear is called before the object's persistence field is cleared. There are several reasons to make the JDO implementation to clear the persistent state of the object. This method can be used to clear the cache data and empty relationship of the non-persistent field. In this method you The persistence field cannot be accessed. 4) JDopredelete is called before the object is removed from the data store. In this method you can access the persistence field. Use this method to delete the related object, you must delete the related relationship of the object
And the persistencecapable interface is different. If you want to get a survival review, you must display the implementation instanceCallbacks interface
4.5JDO logo
Java has two types of object ID: digital one identification and nature logo. If the value of the two references is the same, they point to the same JVM instance in the memory. You can use == operators to test this situation. Nature ID according to customizable The standard checks if the two objects are equal. Usually test the nature ID with the equals method. By default, this method usually uses a digital identity. JDO introduces another object identifier, called a JDO ID. It is used to test two persistence Whether the object provides the same data status Each persistence instance is encapsulated in the JDO identification object. You can call the JDOHELPER's getObjectID method to obtain the JDO identification object of the persistence instance. If you use the equals method, you get two JDO IDs The object is equal, then they provide the same data status.
If you use only one PersistenceManager, use the == operator to test whether two persistence objects provide the same data status. JDO requires that each PersistenceManager can only include an object in the virtual machine, which points to the unique data record. In this PersistenceManager management object, the JDO ID and digital identity is equivalent. This is the "single value" requirement that will be talked. The single-value requirements are very important, otherwise the data integrity cannot be guaranteed. Please think about this situation There are two different objects in the same persistenceManager, they provide the same persistence data. If you change one of the objects, which object's data is written to the data store, is the changed data, or Data before changing? When you see two different "versions of the same data, how do you write a logical processing section of the program? This thank you, make us no need to answer this question.
There are three types of JDO logo. But for most programs, only two are important: data storage identity and application ID. Most JDO implementation supports data storage ID, some also support application ID. All inheritance The persistence class of the tree must use the same JDO logo. 4.5.1. Data storage ID
The data storage identity is managed by JDO implementation. It doesn't matter with your persistence field. You don't have to recite which class will be used by JDO identification objects. You don't have to remember what data is used to create logo. You just need to remember The following criteria: Class must be a PUBLIC class. You must serialize all non-static fields must be a public and serialization class. There must be a confusing-free constructor class having an open string parameter. The class must be overloaded to Tostring Method. This constructor is used to create a new JDO identification object, .... Note: KODO allows you to customize the style of data storage identity
4.5.2.1. Application ID
The application ID is managed by the developer. Under the application ID, the value of an object persistence field determines its JDO ID. Determine the field value of the object identity is called the primary key field. In all objects of the same type, each The value of the primary key field of the object must be unique. When using the application identity, the Equals and HashCode methods that can lastily depends on the primary key field. Similarly, use the application ID to be used to support class by JDO identification object. The application identity must comply with all data storage identity guidelines. Comply with the following requirements: The name of the non-static field name must contain the name of the corresponding persistent class primary key field, and the field type must be consistent. Class Equals and HashCode methods must be used All the fields of the associated primary key fields. The embedded class must be static. All classes of the same inherited level must use the same application ID. Or each class has its own application identity class, this class's inheritance hierarchy map Have the inheritance level of its class. (See 4.5.2.1 Application Identification Hierarchy) All primary key fields must be a basic type, or a basic type of packaging, string, especially, other persistence instances cannot be used as the main key field.
These guidelines use you can create an application identifier object: or from the value of the primary key field of the persistent class instance, or the string returned from another TOString method of another identifier object. Although it is not necessary, you must use you The application identity registers the corresponding sustainable class to the JVM. Typical is done by the static part of the application identification class code. Just as the following example, this registration process can avoid this, not being used by your application. The type will find it.
4.5.2.1 Application Identification Level
There is a way to avoid using a single application ID class identify the entire inheritance level. That is to use an application identity class at each inheritance level. Use the criteria as follows: 1) The inheritance hierarchy of the application ID class can clearly reflect the persistent class determination Hierarchy, for example, if there is an abstract class Person, another abstract class Employee inherits Person, non-abstract class fulltimeemployee inherits Employee, non-abstract class Manager inherits FullTimeemPloyee, then the corresponding application ID class is: Abstract Personid class, abstraction Inheriting the EmployeeID class, non-abstract inherited Employeeid's FullTimeemPloyeeid class, non-abstract inherited FullTimeemPloyeid's ManagerID class
2) The subclass of the object identification hierarchy must define an additional primary key field until the parent level becomes non-abstracted. In the foregoing example, Personid must define a ID field called PK1, EMPLOYEEID must define pk2, fulltimeemployeid definition PK3, and ManagerID does not have to be Define additional primary key fields because it is a subclass of non-abstract classes
3) Do not have to identify primary keys for each non-abstract application identity. In the previous example, the Personid and EmployeeID classes may not define primary key fields, while inheriting their non-abstract classes must define one or more primary key fields.
4.6 Conclusions This chapter introduces all the regulations in the written persistent class in JDO. However, JDO does not use your lasting class unless you create JDO metadata. The next seal will be described in detail.
