JP5673431B2 - Information processing apparatus, information processing method, and program - Google Patents

Description

  The present invention relates to an information processing apparatus, an information processing method, and a program.

  Java (registered trademark), C ++, and the like are known as object-oriented programming languages. In a program created using an object-oriented programming language, a function is realized by a cooperative operation between objects. An object has methods and data, and its structure is defined as a class. In other words, an object is an instance of a class.

  Object relation mapping (ORM) is known as a technique for persisting objects in a data store such as a database.

  FIG. 1 is a diagram for explaining object relationship mapping. As shown in the figure, in the object relationship mapping, the association between the object and the record of the data store is automatically performed. That is, in the object relationship mapping, conversion from an object to a data store record, conversion from a data store record to an object, and the like are automatically performed. Further, in the object relationship mapping, the association (reference relationship) between objects is automatically associated and converted with records in the data store.

  FIG. 2 is a diagram illustrating an example of object relationship mapping regarding objects having a reference relationship.

  In the figure, an Employee object and a department object are shown. A reference relationship R1 is formed between the Employee object and the department object. That is, the Employee object refers to the department object.

  In this case, according to the object relationship mapping, the Employee object and the department object are converted into a table record corresponding to each object and made permanent. In the figure, the Employee object is converted into a record of the table T1 and made permanent. The department object is converted into a record of the table T2 and is made permanent.

  Further, the reference relationship R1 is converted into a record item corresponding to the Employee object and made permanent. In the figure, the item is “Department ID <FK>” in the table T1. The value of the item is interpreted as a reference relationship to the object corresponding to the record in the table T2 by object relationship mapping.

  As is clear from the above, by using the object relationship mapping, it is not necessary to be aware of the structure of the data store to which the object is persisted on the source code of the application program that uses the object.

  In Java (registered trademark), JPA (Java (registered trademark) Persistence API), JDO (Java (registered trademark) Data Objects), and the like are established as standard specifications of API (Application Program Interface) for object relationship mapping. .

JP 2001-51879 A

  On the other hand, using a plurality of data stores having different characteristics such as RDB (Relational Database) and KVS (Key-Value Store), for example, requires a large-scale data processing. It is said that it is effective. Therefore, when such a system is implemented by object-oriented programming, each object is distributed to a plurality of data stores having different characteristics using an implementation of object relationship mapping (hereinafter referred to as “object relationship mapping implementation”). It is possible to make it permanent.

  Usually, however, objects in a reference relationship need to be persisted in a single data store. This is because of the referential integrity constraint of the object relationship mapping that attempts to maintain the consistency of each reference relationship (a state in which a reference destination object exists in the data store) within a single data store. Therefore, under the referential integrity constraint, each object in the reference relationship cannot be persisted to a different data store.

  Specifically, the reference relationship between objects with multiple reference destinations is a collection-type field (hereinafter referred to as “reference element collection”) that has a reference to the reference destination object (object reference) as an element in the reference source object. Field ”). The reference (reference) is data indicating that an object is referred to. The reference value is, for example, the memory address of the reference destination object. A field refers to an attribute item that an object has and is also called a member variable. A collection refers to a data structure that can store a plurality of data such as lists and sets.

  In order to persist the reference source object A in the data store, the reference element collection field of the object A is given to the object relationship mapping implementation as a persistence target. However, if the persistence destination data store of the object A is different from the persistence destination data store of the object group referenced by the reference element collection field, the persistence of the object A becomes an error due to the referential integrity constraint.

  Therefore, an object of one aspect is to provide an information processing apparatus, an information processing method, and a program capable of perpetuating a reference relationship between objects across a plurality of data stores.

  In one plan, the information processing apparatus includes the first class attribute so that the first attribute that is a set of objects of the second class is excluded from the persistence target among the attributes of the first class. An exclusion unit for changing definition information; an addition unit for adding a second attribute that is a set of identification attribute values of the second class object to the definition information; and the second attribute for the first attribute. For the processing according to the setting request for the class object set, the definition is set so that the set of the identification attribute values of the second class objects included in the set is set to the second attribute. A linked object that reflects a change request for the first attribute in the first attribute and the second attribute for the first change unit that changes information and the process according to the acquisition request for the first attribute As return to, and a second changing unit configured to change the definition information.

  According to one aspect, a reference relationship between objects can be made persistent across a plurality of data stores.

It is a figure for demonstrating object relationship mapping. It is a figure which shows the example of the object relationship mapping regarding the object which has a reference relationship. It is a figure which shows the hardware structural example of the information processing apparatus in embodiment of this invention. It is a figure which shows the function structural example of the information processing apparatus in embodiment of this invention. It is a figure which shows an example of the reference relationship between the objects in this Embodiment. It is a figure which shows the state by which the identification element collection field was added to the Department object. It is a figure which shows the state of the Department object before calling the setter of a reference element collection field. It is a figure which shows the state of the Department object after calling the setter of a reference element collection field. It is a figure which shows the state of the Department object in which the reference to an interlocking collection object is not set to the employees field. It is a figure for demonstrating an interlocking collection object. It is a figure which shows the example of a definition of an interlocking collection class. It is a flowchart for demonstrating an example of the process sequence of the selection process of a change object class definition file. It is a figure which shows the example of a definition of the class definition file of a Department class. It is a figure which shows the example of a definition of the class definition file of an Employee class. It is a figure which shows the structural example of an object arrangement | positioning definition memory | storage part. It is a sequence diagram for demonstrating an example of the process sequence of the change process of a change object class definition file. It is a figure which shows the example of a definition of the class definition file of a Department class after the addition of an identification element collection field. It is a figure which shows the example of a definition of the class definition file of a Department class after a change is made regarding a reference element collection field. It is a sequence diagram for demonstrating an example of the process sequence at the time of perpetuation of an object. It is a sequence diagram for demonstrating an example of the process sequence at the time of perpetuation of an object. It is a 1st figure which shows the example of the state of each object. It is a 2nd figure which shows the example of the state of each object. It is a 3rd figure which shows the example of the state of each object. It is a figure which shows the example of the permanent state of a Department object and an Employee object. It is a sequence diagram for demonstrating an example of the process sequence at the time of acquisition of the object made permanent. It is a sequence diagram for demonstrating an example of the process sequence at the time of acquisition of the object made permanent. It is a sequence diagram for demonstrating an example of the process sequence at the time of acquisition of the object made permanent. It is a 4th figure which shows the example of the state of each object. It is a 5th figure which shows the example of the state of each object. It is a sequence diagram for demonstrating an example of the process sequence performed at the time of a dirty check. It is a sequence diagram for demonstrating an example of the process sequence performed at the time of a dirty check. It is a 6th figure which shows the example of the state of each object. It is a 7th figure which shows the example of the state of each object. It is a figure which shows the example of the permanent state of the Department object and Employee object after a dirty check.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 3 is a diagram illustrating a hardware configuration example of the information processing apparatus according to the embodiment of the present invention. The information processing apparatus 10 in FIG. 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, and the like that are connected to each other via a bus B.

  A program for realizing processing in the information processing apparatus 10 is provided by the recording medium 101. When the recording medium 101 on which the program is recorded is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program need not be installed from the recording medium 101 and may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 executes functions related to the information processing apparatus 10 according to a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network.

  An example of the recording medium 101 is a portable recording medium such as a CD-ROM, a DVD disk, or a USB memory. An example of the auxiliary storage device 102 is an HDD (Hard Disk Drive) or a flash memory. Both the recording medium 101 and the auxiliary storage device 102 correspond to computer-readable recording media.

  FIG. 4 is a diagram illustrating a functional configuration example of the information processing apparatus according to the embodiment of the present invention. In the figure, an information processing apparatus 10 includes a change target selection unit 11, a class definition change unit 12, a linked collection object generation unit 13, an O / R mapper access unit 14, an O / R mapper unit 15a, and an O / R mapper unit. 15b etc. Each of these units is realized by processing that a program installed in the information processing apparatus 10 causes the CPU 104 to execute. The information processing apparatus 10 includes a class definition file storage unit 21, an object arrangement definition storage unit 22, a data store 16a, a data store 16b, and the like. Each of these storage units or data stores can be realized by using a storage device connected to the auxiliary storage device 102 or the information processing device 10 via a network.

  The data store 16a and the data store 16b (hereinafter referred to as “data store 16” when they are not distinguished from each other) are data stores such as a database that are used as an object persistence destination. In the present embodiment, the data store 16a and the data store 16b make an object group having a reference relationship permanent across the reference relationship.

  FIG. 5 is a diagram illustrating an example of a reference relationship between objects in the present embodiment. In the figure, a Department object is an instance of a Department class that represents one department. The Department object (Department class) has a field whose field name is “id” or “employees”. A field refers to an attribute item that an object has, and is also called a member variable. The id field of the Department object has information (for example, department name) that uniquely identifies the department as a value. The “employees” field takes a reference (object reference) to a reference element collection object, which is a collection type object having a reference (object reference) to the Employee object as an element. In other words, the employee field is a set of employee objects (object references). Reference (object reference) is data indicating that an object is referred to. The reference value is, for example, the memory address of the reference destination object. Note that a collection-type field whose elements are references to other objects, such as the “employees” field, is hereinafter referred to as “reference element collection field”.

  The Employee object is an instance of the Employee class that represents a single employee. In the figure, the Employee object has a field whose field name is “id” or “name”. The id field of the Employee object has information (for example, employee number) uniquely identifying the employee as a value. The name field has the employee's name as a value.

  In the figure, a Department object refers to a plurality of Employee objects via an emloyees field. That is, the department object and the employee object have a one-to-many reference relationship. This expresses that a plurality of employees belong to one department.

  In the present embodiment, a field that can uniquely identify a target (in this embodiment, a department or an employee) represented by each object is referred to as an “identification attribute”. For example, in the Employee object, the id field corresponds to the identification attribute.

  Returning to FIG. The data store 16a is a data store used as a permanent destination of the Department object. The data store 16b is a data store that is used as a permanent destination of the Employee object. The data store 16a may be, for example, an RDB (Relational Database). The data store 16b may be, for example, KVS (Key-Value Store). However, the data store 16a and the data store 16b may be data stores having the same form. That is, both may be RDB or both may be KVS. Further, the data store 16a and the data store 16b may be data stores of a form other than RDB or KVS.

  The O / R mapper unit 15a is an implementation of object relationship mapping regarding a Department object (Department class). That is, the O / R mapper unit 15a performs conversion (permanent) to a record of the data store 16a, conversion from a record of the data store 16a, and the like regarding the Department object.

  The O / R mapper unit 15b is an implementation of object relationship mapping regarding an Employee object (Employee class). That is, the O / R mapper unit 15b performs conversion of the employee object into a record in the data store 16b, conversion from a record in the data store 16a, and the like.

  Note that the O / R mapper unit 15a and the O / R mapper unit 15b are, for example, JPA (Java (registered trademark) Persistence API) and JDO (Java (registered trademark) Data Objects) which are standard specifications for object relationship mapping. It may be compliant. When conforming to JPA, the O / R mapper 15a and the O / R mapper 15b correspond to an EntityManager.

  The O / R mapper access unit 14 wraps a plurality of O / R mapper units 15 such as an O / R mapper unit 15a and an O / R mapper unit 15b, and makes each object permanent (user) The embodiment has a function of hiding from the application program 17). More specifically, the O / R mapper access unit 14 has the same API (Application Program Interface) as the O / R mapper unit 15a and the O / R mapper unit 15b, and is a persistence target or an acquisition target from the data store 16. Depending on the class of the object, the persistence process or the acquisition process is delegated to the O / R mapper unit 15a or the O / R mapper unit 15b.

  The class definition file storage unit 21 stores a file (hereinafter referred to as “class definition file”) in which definition information of classes of various objects used from the application program 17 is recorded. Class definition information refers to information indicating the definition of fields, methods, and the like possessed by a class. That is, the class definition information can be said to be information indicating the structure of an object that is an instance of the class. For example, the class definition information may be a class source code, or a compiled program (such as Java (registered trademark) bytecode) in which the class source code is compiled. For example, it may be a Java (registered trademark) class file. The function of the application program 17 is not limited to a predetermined one. The application program 17 may be an application that executes processing in response to a request from a client, such as a Web application, or may be an interactive application.

  The change target selection unit 11 selects a class definition file to be changed (or converted) from the class definition file group stored in the class definition file storage unit 21. The class definition file selected by the change target selection unit 11 is hereinafter referred to as “change target class definition file”. In the present embodiment, a class definition file of a class that refers to an object of another class and that is different from the other class and the data store 16 that is the persistence destination is a change target. In the present embodiment, the class definition file of the Department class is selected as the class definition file to be changed. “Change” refers to rewriting at least part of the contents of the class definition file.

  The class definition changing unit 12 executes a change process on the change target class definition file to generate a changed class definition file f1. More specifically, the class definition changing unit 12 includes an identification attribute adding unit 121, a reference attribute excluding unit 122, a reference attribute setting method changing unit 123, a reference attribute acquiring method changing unit 124, and the like.

  The identification attribute adding unit 121 uses a collection type object (hereinafter, referred to as an “identification element collection object”) having an element as the value of the identification attribute of an object referenced from the class object related to the class definition file to be changed. Add the definition of the field to be changed (hereinafter referred to as “identification element collection field”) to the class definition file to be changed. That is, in this embodiment, the identification attribute adding unit 121 adds the definition of the identification element collection field whose element is the value of the id field of the Employee object to the class definition file of the Department class.

  FIG. 6 is a diagram showing a state in which an identification element collection field is added to the Department object.

  In the figure, a field having “employeesIds” as a field name is added to the Department object. The employeesIds field is an identification element collection field. In the identification element collection object set (assigned) in the employeesIds field, a set of id field values of the employee object that is an element of the employees field that is a reference element collection field is stored.

  The identification attribute adding unit 121 also adds a setter and a getter related to the identification element collection field to the change target class definition file. A setter is a method that accepts a value setting request for a field corresponding to the setter. A getter is a method that accepts an acquisition request for the value of a field corresponding to the getter.

  The reference attribute exclusion unit 122 excludes the reference element collection field (employees field) included in the change target class definition file from the object to be persisted by the object relationship mapping implementation (O / R mapper unit 15a). Execute the process. Specifically, the reference attribute exclusion unit 122 is a qualifier (@Transient annotation described later) indicating that the reference element collection field included in the change target class definition file is not subject to persistence. Is added. The @Transient annotation is an effective qualifier when JPA is used. For example, when JDO is used, @NotPersistent may be added as the qualifier.

  The reason why the reference element collection field is excluded from the persistence target is to avoid the occurrence of an error due to the referential integrity constraint of the object relationship mapping. That is, in the present embodiment, the Department object is persisted in the data store 16a, and the Employee object is persisted in the data store 16b. In such a situation, consider a case where the employee field, which is the reference element collection field of the Department object, is persisted to the data store 16a as it is by the O / R mapper unit 15a. In this case, each Employee object referenced by the employee field is required to exist in the data store 16a due to the referential integrity constraint. However, since the Employee object is not persisted in the data store 16a, the above referential integrity constraint cannot be satisfied. As a result, persistence of the Department object results in an error. In order to avoid the occurrence of such a situation, the reference element collection field is excluded from the persistence target.

  Instead of excluding the reference element collection field from the persistence target, the identification element collection field whose element is the value of the identification attribute of each Employee object referenced by the Department object is persisted. As a result, it is possible to avoid that the reference relationship between the Department object and the Employee object is lost due to the persistence of both objects. This is because, as will be described later, based on the identification element collection field that is made permanent, the Employee object that is the reference destination of each Department object that is made permanent can be specified.

  Even if the identification element collection field is made permanent in the data store 16a via the O / R mapper unit 15a, an error due to referential integrity constraint does not occur. The element of the identification element collection field is not a reference but a value of a general data type such as a character string or a numerical value. Therefore, the O / R mapper unit 15a and the data store 16a handle the identification element collection field as a simple set of character strings or numerical values.

  The reference attribute setting method changing unit 123 changes the definition content of the setter of the reference element collection field in the change target class definition file. That is, in this embodiment, the reference attribute setting method changing unit 123 changes the definition contents of the set related to the employees field of the Department object. Specifically, the reference attribute setting method changing unit 123 sets the setter so that the reference relationship as shown in FIG. 8 is formed with respect to the department object and the employee object in the state as shown in FIG. Change the definition of.

  FIG. 7 is a diagram illustrating the state of the Department object before calling the setter of the reference element collection field.

  In the Department object in the figure, the values of the employees field and the employeesIds field are empty. For example, a state immediately after the Department object is generated may be assumed.

  In this state, when the specified reference element collection object shown in the figure is specified as the setter argument of the reference element collection field (employees field) of the Department object, the changed setter is shown in FIG. Generate a state as shown.

  FIG. 8 is a diagram illustrating the state of the Department object after calling the setter of the reference element collection field.

  The changed setter causes the linked collection object generation unit 13 to generate a linked collection object in response to the call. As shown in the figure, the linked collection object has a field whose field name is “vals” or “ids”. In the vals field, a reference to the reference element collection object specified in the argument of the setter is set. Also, in the ids field, a reference to an identification element collection object whose element is the id field value of each Employee object referenced from the reference element collection object is set. The reference to the identification element collection object is also set in the employeesIds field of the Department object. Furthermore, a reference to the linked collection object is set in the employee field of the Department object. As a result, the reference relationship as shown in FIG. 8 is formed.

  The reference attribute acquisition method changing unit 124 changes the definition content of the getter of the reference element collection field in the change target class definition file. That is, in the present embodiment, the reference attribute acquisition method changing unit 124 changes the definition content of the getter related to the employees field of the Department object. Specifically, the reference attribute acquisition method changing unit 124 returns a reference to the linked collection object when the reference to the linked collection object is set in the employees field of the Department object for the getter. Change the definition to The case where the reference to the linked collection object is set in the employees field is, for example, the case where the Department object has a state as shown in FIG.

  In addition, when the reference to the linked collection object is not set in the employees field for the getter, the reference attribute acquisition method changing unit 124 changes the definition content so as to execute the following process.

  FIG. 9 is a diagram illustrating a state of a Department object in which the reference to the linked collection object is not set in the employees field.

  In the Department object shown in the figure, the value of the employees field is empty. On the other hand, a reference to the identification element collection object is set in the employeesIds field. For example, the figure shows a state immediately after the Department object that has been made permanent in the data store 16a is acquired from the data store 16a.

  When the Department object is in the state shown in FIG. 9, in the changed getter, the Employee object group is passed through the O / R mapper unit 15b using each numerical object included in the identification element collection object as a key. Obtained from the data store 16b. Furthermore, a reference element collection object having the acquired employee object as an element is generated. In addition, a linked collection object is generated, and a reference to the reference element collection object is set in the vals field of the linked collection object. Further, in the ids field of the linked collection object, a reference to the identification element collection object shown in FIG. 9 is set. Further, a reference to the linked collection object is set in the employee field of the Department object. As a result, the state described in FIG. 8 is generated in response to the call to getter after the change. The changed getter returns the value of the employees field, that is, the reference to the linked collection object.

  As will be described later, the conjunction collection object implements the same interface (List interface) as the reference element collection object. Therefore, the application program 17 that called the getter handles the returned linked collection object as a reference element collection object. This means that the source code of the application program 17 is not affected by the change of the change target class definition file.

  For example, the application program 17 requests the linked collection object to acquire, add, or delete the Employee object. In response to such a request, the conjunction collection object behaves as follows.

  FIG. 10 is a diagram for explaining the linked collection object. As shown in the figure, the conjunction collection object delegates the processing according to the request for acquisition, addition, or deletion of the employee object to the reference element collection object set in the vals field. Accordingly, the acquisition, addition, or deletion of the Employee object is executed in the reference element collection object. The linked collection object further reflects the addition or deletion of the Employee object in the reference element collection object in the identification element collection object set in the ids field. Specifically, the linked collection object adds the id field value of the addition-target Employee object to the identification element collection object. In addition, the linked collection object deletes the value of the id field of the Employee object to be deleted from the identification element collection object.

  In order to cause the linked collection object to execute the process as described above, for example, the class of the linked collection object (linked collection class) is defined as shown in FIG.

  FIG. 11 is a diagram illustrating a definition example of a linked collection class. In the drawing, an example in which the class name of the linked collection class is “MetaList” is shown.

  In the figure, a description 316 indicates that the MetaList class (linked collection class) implements a List interface that is an example of a collection type. As will be described later, the reference element collection object also implements the List interface.

  The description d311 is the definition of the vals field. The description d312 is the definition of the ids field. A description d313 is a definition of a getIds method that is a getter of the ids field. In addition, the definition regarding the setter in the ids field and the getter and setter in the vals field are omitted for convenience.

  The description d314 is an implementation of the add method defined in the List interface. The add method executes processing corresponding to a request for adding an object of a class that implements the MetaEntity interface, which is specified as an argument. In the add method of the MetaList class, element addition processing is defined for each of the identification element collection object and the reference element collection object.

  The description d315 is an implementation of the remove method defined in the List interface. The remove method of the MetaList class executes processing according to a request for deleting an object of a class that implements the MetaEntity interface, which is specified as an argument. In the remove method of the MetaList class, deletion processing of elements from each of the identification element collection object and the reference element collection object is defined.

  In the present embodiment, the Employee object is designated as an argument such as an add method and a remove method. That is, the Employee class implements the MetaEntity interface.

  In this way, the linked collection object links or synchronizes the states of the reference element collection object and the identification element collection object, and as a result, consistency is always ensured between the two.

  One of introduction significance or existence significance of the linked collection object is, for example, as follows.

  In an object-oriented program, the value of a field of a certain object can be assigned to a left-side value represented by a local variable (temporarily usable data storage area) or the like. This property is the same for a field whose value is a reference to a collection object.

  Therefore, for example, it is assumed that the getter before the change related to the employees field is called in the state where the Department object is as shown in FIG. In this case, there is a possibility that a reference to the reference element collection object set in the employees field is assigned to a local variable of the application program 17 that is the calling source of getter. Then, there is a possibility that the application program 17 adds or deletes the Employee object to the reference element collection field via the local variable.

  However, the Department object cannot detect the addition or deletion of the Employee object to the reference element collection field via the local variable. This is because the local variable has no relationship with the Department object. Therefore, the value of the id field of the Employee object added to the reference element collection field is not added to the identification element collection field. As a result, a mismatch occurs between the reference element collection field and the identification element collection field.

  As described above, of the reference element collection field and the identification element collection field, only the identification element collection field is targeted for persistence. Then, changes to the reference element collection field will not be properly persisted. That is, a function generally called “dirty check” cannot be effectively operated. Dirty check is a function that automatically detects the difference between the reference relationship between objects in memory and the reference relationship between records persisted in the data store, and reflects the difference in the data store. Say.

  On the other hand, if the Department object is in the state as shown in FIG. 8, a reference to the linked collection object is assigned to a local variable of the application program 17 that called the getter by calling the getter after the change related to the employees field. Is done. Then, the addition or deletion of the Employee object via the local variable is reflected on both the reference element collection object and the identification element collection object by the linked collection object as described in FIG. As a result, the dirty check can be effectively operated.

  For this reason, a linked collection object is introduced in the present embodiment.

  Hereinafter, a processing procedure executed by the information processing apparatus 10 will be described. FIG. 12 is a flowchart for explaining an example of the processing procedure of the selection process of the change target class definition file.

  In step S <b> 101, the change target selection unit 11 selects one class definition file from the class definition file group stored in the class definition file storage unit 21 and reads the class definition file. The class related to the selected class definition file is hereinafter referred to as “target class”. For example, when the class definition file of the Department class is selected, the definition information shown in FIG. 13 is read.

  FIG. 13 is a diagram illustrating a definition example of a class definition file of a Department class.

  In the class definition file C1 shown in the figure, the description d111 is the definition of the id field. A description d112 is a definition of a getId method that is a getter of the id field. A description d113 is a definition of a setId method which is a setter of the id field.

  A description d114 is a definition of an employees field that is a reference element collection field. In other words, the employee field is a List type field whose element is a reference to the Employee object. The List type is a kind of collection type. A description d115 is a definition of a getEmployees method that is a getter of the employees field. A description d116 is a definition of a setEmployees method which is a setter of the employees field. Description d117 is an implementation for the getPrimaryKey method defined in the MetaEntity interface. In other words, the description d118 indicates that the Department class implements the MetaEntity interface defined by JPA. Therefore, the Department class includes an implementation of the method defined in the MetaEntity interface. The getPrimaryKey method is a method that returns a primary key (that is, a unique identification attribute value for each object). Therefore, in the getPrimaryKey method implemented in the Department class, the value of the id field is returned.

  When the class definition file of the Employee class is selected, the definition information shown in FIG. 14 is read.

  FIG. 14 is a diagram illustrating a definition example of the class definition file of the Employee class.

  In the class definition file C2 shown in the figure, the description d211 is the definition of the id field. A description d212 is a definition of a getId method that is a getter of the id field. The description d213 is a definition of a setId method that is a setter of the id field. The description d214 is an implementation for the getPrimaryKey method defined in the MetaEntity interface. In other words, the description d215 indicates that the Employee class implements the MetaEntity interface. Therefore, the Employee class includes an implementation of the method defined in the MetaEntity interface. In the getPrimaryKey method implemented in the Employee class, the value of the id field is returned.

  Subsequently, the change target selection unit 11 determines whether or not the target class definition file includes a collection type field (reference element collection field) having a reference to the object as an element (S102). This determination is performed based on, for example, the presence or absence of a field to which the @OneToMany annotation is added. That is, the @OnToMany annotation is a qualifier indicating that the field to which the annotation is added is a field for holding a one-to-many reference relationship.

  The class definition file C1 of the Department class shown in FIG. 13 includes the @OnToMany annotation in the description d114. Therefore, when the class definition file C1 is the target class definition file, the determination in step S102 is Yes.

  On the other hand, the class definition file C2 for the Employee class shown in FIG. 14 does not include the @OnToMany annotation. Therefore, when the class definition file C2 is the target class definition file, the determination in step S102 is No.

  Note that the determination in step S102 may be performed based on whether or not there is a field of a collection type and a collection element is a reference to an object of another class, instead of the presence or absence of the @OnToMany annotation.

  In other words, the description d114 of the class definition file C1 (FIG. 13) of the Department class includes a collection type (List type) employees field having a reference to the object of the Employee class as an element. Therefore, regarding the class definition file C1, the determination in step S102 is Yes.

  On the other hand, the class definition file C2 (FIG. 14) of the Employee class does not include a collection type field whose element is a reference. Therefore, the determination in step S102 is No for the class definition file C2.

  When the target class definition file includes a reference element collection field (Yes in S102), the change target selection unit 11 includes a persistence destination of an object of a class related to the target class definition file (hereinafter referred to as “target class”), It is determined whether or not the object persistence destination of a class (hereinafter referred to as “reference destination class”) designated as a reference destination in the reference element collection field is different (S103). This determination is made with reference to the object arrangement definition storage unit 22.

  FIG. 15 is a diagram illustrating a configuration example of the object arrangement definition storage unit. In the figure, the object arrangement definition storage unit 22 stores a class name, an O / R mapper ID, a persistence unit name, and the like for each class of objects to be persisted. The class name is the name of the class of the object to be made persistent. The O / R mapper ID is an identifier of the O / R mapper unit 15 that executes persistence of an object of each class. In the present embodiment, the object of the Department class is made permanent by the O / R mapper unit 15a. The Employee class object is made permanent by the O / R mapper unit 15b. Therefore, the O / R mapper ID of the O / R mapper unit 15a is stored for the Department class, and the O / R mapper ID of the O / R mapper unit 15b is stored for the Employee class. The persistence unit name is the name of the persistence unit. The persistence unit refers to a file in which setting information for the O / R mapper unit 15 is described in JPA. For example, each O / R mapper unit 15 identifies the data store 16 that is the persistence destination based on the setting information described in the persistence unit.

  In the object arrangement definition storage unit 22, when the O / R mapper ID is different, the persistence destination is different. Therefore, in step S103 described above, the change target selection unit 11 determines whether both the O / R mapper ID corresponding to the target class and the O / R mapper ID corresponding to the reference class are different. Judge the difference of the persistence destination of the class object.

  For example, when the target class is the Department class, the reference class is the Employee class from the description d114 of the class definition file C1 (FIG. 13). In the object arrangement definition storage unit 22 shown in FIG. 15, the O / R mapper ID for the Department class is different from the O / R mapper ID for the Employee class. Therefore, it is determined that the persistence destination of the object of the target class is different from the persistence destination of the object of the reference class.

  When the persistence destination of the object of the target class is different from the persistence destination of the object of the reference class (Yes in S103), the change target selection unit 11 determines that the target class definition file is a change target ( S104). That is, the target class definition file is selected as the change target class definition file. Specifically, the target class definition file may be copied to a predetermined folder in which the change target class definition file is to be stored. Alternatively, the change target selection unit 11 may request the class definition change unit 12 to execute a change process related to the target class definition file.

  On the other hand, when the persistence destination of the object of the target class is the same as the persistence destination of the object of the reference class (No in S103), the change target selection unit 11 does not change the target class definition file. Is determined. In this case, the object of the target class and the object of the reference class are persisted in the single data store 16 and do not violate the referential integrity constraint.

  The process of FIG. 12 is executed for each class definition file stored in the class definition file storage unit 21. Therefore, a plurality of class definition files may be selected as the change target class definition files.

  Next, the change process of the change target class definition file will be described. FIG. 16 is a sequence diagram for explaining an example of the processing procedure of the change process of the change target class definition file. The process of FIG. 12 may be executed synchronously with the process of FIG. 12 or may be executed asynchronously with the process of FIG. For example, when the change target selection unit 11 requests the class definition change unit 12 to execute the change process in step S104 of FIG. 12, the process of FIG. 16 uses the target class definition file at that time as the process target. It is executed synchronously with the processing of FIG. On the other hand, when the change target class definition file is copied to a predetermined folder in step S104 of FIG. 12, the process of FIG. 16 is executed in batch with respect to one or more change target class definition files copied to the folder. May be.

  In any case, the processing in FIG. 16 may be executed when the change target class definition file is loaded. The time when the change target class definition file is loaded is when the application program 17 that uses the class defined in the change target class definition file is started. In the case of Java (registered trademark), a Java (registered trademark) class file is an example of a class definition file. The contents of the Java (registered trademark) class file are bytecodes compiled by the Java (registered trademark) compiler, but can be rewritten at the time of loading using a code injection mechanism or the like. The code injection mechanism is a mechanism that accepts a Java (registered trademark) class file as input, inserts a program different from the original program, changes logic, and adds annotations to program elements such as fields or methods. It is.

  In step S <b> 111, the class definition changing unit 12 requests the identification attribute adding unit 121 to perform change processing for one change target class definition file. Here, a case where the class definition file C1 of the Department class is the target of the change process is taken as an example. Subsequently, the identification attribute adding unit 121 adds an identification element collection field corresponding to the reference element collection field in the change target class definition file to the change target class definition file using, for example, a code injection mechanism (S112). At this time, the identification attribute adding unit 121 also adds the definitions of the setter and getter of the identification element collection field to the change target class definition file.

  FIG. 17 is a diagram illustrating a definition example of the class definition file of the Department class after the identification element collection field is added. In FIG. 17, the same parts as those in FIG. 13 are denoted by the same reference numerals, and the description thereof is omitted.

  In FIG. 17, description d121, description d122, and description d123 are parts added in step S112. That is, the employeesIds field shown in the description d121 is an identification element collection field corresponding to the employees field shown in the description d114. The getEmployeesIds method shown in the description d122 is a getter of the employeesIds field. The setEmployeesIds method shown in the description d122 is a setter of the employeesIds field.

  The element type of the employeesId field is a string type (character string type). This is because the identification attribute type of the Employee class that is the reference destination is the String type. Which of the fields of the Employee class is the identification attribute is determined based on the @Id annotation. That is, it is determined that the field to which the @Id annotation is added is a field having an identification attribute. In the class definition file C2 of the Employee class (FIG. 14), the @Id annotation is added to the id field in the description d211. Therefore, it is determined that the id field is an identification attribute. The type of the id field is a string type. Therefore, the element type of the employeesId field is a string type.

  Note that the Department object generated based on the definition information shown in FIG. 17 forms a reference relationship as shown in FIG.

  Subsequently, the class definition changing unit 12 requests the reference attribute excluding unit 122 to execute change processing on the change target class definition file (S113). The reference attribute exclusion unit 122 adds, for example, a definition for excluding the reference element collection field in the change target class definition file from the persistence target to the change target class definition file using a code injection mechanism (S114).

  Subsequently, the class definition changing unit 12 requests the reference attribute setting method changing unit 123 to execute a change process on the change target class definition file (S115). The reference attribute setting method changing unit 123 changes the definition content of the setter of the reference element collection field in the change target class definition file using, for example, a code injection mechanism (S116). In other words, a process for maintaining the consistency between the reference element collection field and the identification element collection field is added to the setter of the reference element collection field.

  Subsequently, the class definition changing unit 12 requests the reference attribute acquisition method changing unit 124 to execute a change process on the change target class definition file (S117). The reference attribute acquisition method changing unit 124 changes the getter definition content of the reference element collection field in the change target class definition file using, for example, a code injection mechanism (S118). In other words, a process for maintaining consistency between the reference element collection field and the identification element collection field is added to the getter of the reference element collection field.

  FIG. 18 is a diagram illustrating a definition example of the class definition file of the Department class after a change has been made regarding the reference element collection field. The class definition file C1 in FIG. 16 shows the result of executing steps S113 to S118 on the class definition file C1 shown in FIG. In FIG. 18, the same parts as those in FIG.

  In FIG. 18, the description d114, the description d115, and the description d116 in FIG. 17 are changed to a description d114a, a description d115a, and a description d116a, respectively.

  That is, the @Transient annotation is added to the description d114a by executing step S114. The @Transient annotation is a qualifier indicating that the field to which the annotation is added is excluded from the persistence target. That is, the O / R mapper unit 15a and the O / R mapper unit 15b exclude a field to which the @Transient annotation is added from the persistence target when the object is persisted.

  In addition, an underlined portion is added to the description d116a by executing step S116. In the underlined portion, a processing procedure for changing the reference relationship shown in FIG. 7 to the reference relationship shown in FIG. 8 is described.

  Furthermore, an underlined portion is added to the description d115a by executing step S118. The underlined portion describes a processing procedure for returning a reference to the linked collection object when a reference to the linked collection object is set in the employees field. The case where the reference to the linked collection object is set in the employees field means the case where the reference relationship shown in FIG. 8 is formed. Further, in the underlined portion, there is a processing procedure for forming a reference relationship shown in FIG. 8 and returning a reference to the linked collection object when a reference to the linked collection object is not set in the employees field. It has been described. The case where the reference to the linked collection object is not set in the employees field is a case where the Department object has the state shown in FIG.

  This is the end of the modification process for the class definition file C1 of the Department class. That is, the class definition file C1 shown in FIG. 18 is the changed class definition file f1 related to the Department class in the present embodiment. Hereinafter, the class definition file C1 shown in FIG. 18 is referred to as a “modified class definition file f1”.

  Next, a processing procedure executed when an object generated based on the changed class definition file f1 is made permanent will be described.

  19 and 20 are sequence diagrams for explaining an example of a processing procedure when an object is made permanent. FIG. 19 and FIG. 20 illustrate a processing procedure related to one scenario in which object persistence is performed, and does not indicate that object persistence is always executed by the processing procedure.

  In step S201, the application program 17 generates a reference element collection object, for example. The reference element collection object holds its reference by, for example, a local variable of the application program 17. Subsequently, the application program 17 generates one or more Employee objects (S202). The Employee object is generated based on the definition information of the lath definition file C2 shown in FIG.

  Subsequently, the application program 17 adds a reference to the Employee object generated in step S202 as an element of the reference element collection object generated in step S201. Subsequently, the application program 17 generates a Department object (S204). The Dpartment object is generated based on the definition information in the post-change class definition file f1 (FIG. 18).

  Subsequently, the application program 17 calls a setEmployees method that is a setter of the employees field of the Department object (S205). A reference element collection object is specified as an argument of the setEmployees method.

  Subsequently, the Department object executes the process defined in the description d116a of FIG. 18 in the called setEmployees method. That is, the Department object requests the linked collection object generating unit 13 to generate a linked collection object (S206). In the request, the reference element collection object specified as an argument of the setEmployees method is specified.

  Subsequently, the linked collection object generation unit 13 generates a linked collection object (S207). Subsequently, the linked collection object generation unit 13 generates an identification element collection object (S208). At this time, the state of each generated object is, for example, as shown in FIG.

  FIG. 21 is a first diagram illustrating an example of the state of each object. As shown in the figure, immediately after step S208, a Department object, a reference element collection object, an Employee object, a linked collection object, and an identification element collection object are generated. Each Employee object is added as an element of a reference element collection object. Therefore, the reference element collection object refers to each Employee object. No reference relationship is formed between other objects. In addition, no element is added to the identification element collection object.

  Subsequently, the linked collection object generation unit 13 acquires the value of the id field (value of the identification attribute) from each Employee object that is an element of the reference element collection object (S209). Subsequently, the linked collection object generation unit 13 adds the acquired value of each id field to the identification element collection object (S210). As a result, the state of each object is as shown in FIG. 22, for example.

  FIG. 22 is a second diagram illustrating an example of the state of each object. As shown in the figure, by executing Step S210, the value of the id field of each Employee object is added as an element to the identification element collection object.

  Subsequently, the linked collection object generation unit 13 sets (substitutes) a reference to the reference element collection object in the vals field of the linked collection object. Further, the linked collection object generation unit 13 sets (substitutes) a reference to the identification element collection object in the ids field of the linked collection object (S211). As a result, the state of each object is as shown in FIG. 23, for example.

  FIG. 23 is a third diagram illustrating an example of the state of each object. As shown in the figure, a reference relationship from the linked collection object to the identification element collection object and the reference element collection object is formed by executing step S211. In the state shown in FIG. 23, a reference to the linked collection object is returned from the linked collection object generation unit 13 to the Department object as a return value of the setEmployees method.

  Subsequently, the Department object assigns a reference to the linked collection object to the employees field that is a reference element collection field. In addition, the Department object substitutes the value of the vals field of the linked collection object, that is, the reference to the identification element collection object, in the employeesIds field that is the identification element collection field (S212). As a result, the state of each object is as described in FIG.

  Above, the process of the setEmployees method called in step S205 ends. That is, steps S205 to S212 are the processes defined in the description d116a in FIG. As a result of the completion of the process of the setEmployees method, the control of the process returns to the application program 17.

  Subsequently, the application program 17 requests the O / R mapper access unit 14 to start a transaction (FIG. 20: S213). The transaction is a transaction for persisting the Department object, the Employee object, and the like in the data store 16a or the data store 16b.

  Subsequently, the O / R mapper access unit 14 requests the O / R mapper unit 15a and the O / R mapper unit 15b to start a transaction (S214, S215). Subsequently, the application program 17 requests the O / R mapper access unit 14 to make each Employee object permanent (S216). For example, the O / R mapper access unit 14 refers to the object arrangement definition storage unit 22 and determines that the O / R mapper unit 15 corresponding to the Employee object is the O / R mapper unit 15b. Therefore, the O / R mapper access unit 14 requests the O / R mapper unit 15b to make each Employee object permanent (S217).

  Subsequently, the application program 17 requests the O / R mapper access unit 14 to make the Department object permanent (S218). For example, the O / R mapper access unit 14 refers to the object arrangement definition storage unit 22 and determines that the O / R mapper unit 15 corresponding to the Department object is the O / R mapper unit 15a. Therefore, the O / R mapper access unit 14 requests the O / R mapper unit 15a to make the Department object permanent (S217).

  Subsequently, the application program 17 requests the O / R mapper access unit 14 to commit the transaction (reflect the transaction contents to the data store 16) (S220). The O / R mapper access unit 14 requests the O / R mapper unit 15a and the O / R mapper unit 15b to commit a transaction (S221, S222). As a result, each employee object is converted into a record in the data store 16b and made permanent by the O / R mapper unit 15b. Further, the department object is converted into a record of the data store 16a and made permanent by the O / R mapper unit 15a. However, the employees field, which is the reference element collection field of the Department object, is excluded from the persistence target based on the @Transient annotation in the description d114a of the changed class definition file f1 (FIG. 18).

  Immediately after the execution of step S222, for example, as shown in FIG. 24, a Department object and an Employee object are made permanent in each data store 16a.

  FIG. 24 is a diagram illustrating an example of the persistence state of the Department object and the Employee object.

  In the figure, the data store 16b shows an example in which each Employee object in the state shown in FIG. 5 is made permanent. That is, a record corresponding to each of the two Employee objects is generated in the record of the data store 16b. Further, the values of the id field and the name field of the two Employee objects are made permanent as the item values of each record.

  The data store 16a shows an example in which the Department object in the state shown in FIG. 5 is made permanent. That is, a record corresponding to the department object is generated in the data store 16a. Further, the values of the id field and the employeesIds field of the Department object are made permanent as items of the record. In the employeesIds field, each character string object value that is an element of the identification element collection object is made permanent.

  When viewed from the O / R mapper unit 15a and the data store 16a, the value of the employeesIds field is merely a set of character strings and has no meaning as a reference to another object. Further, as described above, the “employes” field, which is a reference element collection field, is not set as a persistence target. Therefore, the Department object can be made permanent without violating the referential integrity constraint and with the reference relationship to the Employee object maintained by the value of the employeesIds field.

  Next, a processing procedure executed when acquiring a persistent object will be described.

  FIG. 25 to FIG. 27 are sequence diagrams for explaining an example of a processing procedure when acquiring a permanent object. FIGS. 25 to 27 illustrate a processing procedure related to one scenario in which object acquisition is performed, and does not indicate that object acquisition is always executed by the processing procedure.

  In step S301, the application program 17 requests the O / R mapper access unit 14 to start a transaction. The transaction is a transaction for acquiring the Department object, the Employee object, and the like from the data store 16a or the data store 16b.

  Subsequently, the O / R mapper access unit 14 requests the O / R mapper unit 15a and the O / R mapper unit 15b to start a transaction (S302, S303).

  Subsequently, the application program 17 requests the O / R mapper access unit 14 to acquire a Department object (S304). In the request, the value of the id field is specified as information for specifying the acquisition-target Department object. For example, acquisition of a Department object whose id field value is “HR” is requested.

  For example, the O / R mapper access unit 14 refers to the object arrangement definition storage unit 22 and determines that the O / R mapper unit 15 corresponding to the Department object is the O / R mapper unit 15a. Therefore, the O / R mapper access unit 14 requests the O / R mapper unit 15a to acquire a Department object whose id field value is “HR” (S305).

  Subsequently, the O / R mapper unit 15a searches the data store 16a for a record whose id item value is “HR”, and the id field value is “HR” based on the record (FIG. 24). A Department object is generated (S306). Subsequently, the O / R mapper unit 15a generates an identification element collection object for storing the value of the “employeesIds” item of the record (S307). Subsequently, the O / R mapper unit 15a adds a character string object corresponding to each character string stored in the employeesIds item of the record as an element of the employeesIds field of the Department object (S308). Note that the state of the Department object immediately after execution of step S308 is, for example, as illustrated in FIG. The Department object in the state shown in FIG. 9 is returned to the application program 17 via the O / R mapper access unit 14. As a result, control of processing returns to the application program 17.

  Subsequently, it is assumed that the application program 17 calls getEmployees, which is a getter related to the employeeIds field of the Department object (FIG. 26: S309). The Department object executes the process defined in the description d115a of FIG. 18 in the called getEmployees method.

  That is, the Department object requests the linked collection object generation unit 13 to generate a linked collection object (S310). In the request, a reference to the identification element collection object set in the employeesIds field is specified as an argument.

  Subsequently, the linked collection object generation unit 13 generates a linked collection object (S311). Subsequently, the linked collection object generation unit 13 generates a reference element collection object (S312). Subsequently, the linked collection object generation unit 13 acquires a character string (that is, the value of the id field of the Employee object) that is each element of the identification element collection object designated as the argument (S313).

  Subsequently, the linked collection object generation unit 13 requests the O / R mapper access unit 14 to acquire an Employee object having the acquired character string as the value of the id field (S314). For example, the O / R mapper access unit 14 refers to the object arrangement definition storage unit 22 and determines that the O / R mapper unit 15 corresponding to the Employee object is the O / R mapper unit 15b. Therefore, the O / R mapper access unit 14 requests the O / R mapper unit 15b to acquire an Employee object having the character string as the value of the id field (S315).

  Subsequently, the O / R mapper unit 15b searches the data store 16b for a record in which the value of the id item matches the character string, and the value of the id field is the character string based on the record (FIG. 24). An employee object is generated (S316). Note that steps S314 to S316 are executed by the number of character strings acquired in step S313. As a result, as many employee objects as the number of the character strings are generated.

  Subsequently, the linked collection object generation unit 13 adds each generated Employee object as an element of the reference element collection object (S317). At this time, the state of each object is as shown in FIG. 28, for example.

  FIG. 28 is a fourth diagram illustrating an example of the state of each object. As shown in the figure, in addition to the Department object acquired by the processing of FIG. 25, a linked collection object and a reference element collection object are generated. Each Employee object is acquired from the data store 16b and is used as an element of the reference element collection object.

  Note that the linked collection object generation unit 13 does not have to acquire the Employee object from the data store 16b at the timing of step S314. Thereafter, when the acquisition of the Employee object is requested to the linked collection object, the Employee object may be acquired from the data store 16b.

  Subsequently, the linked collection object generation unit 13 substitutes a reference to the reference element collection object in the vals field of the linked collection object. Further, the linked collection object generation unit 13 substitutes a reference to the identification element collection object in the ids field of the linked collection object (S318). As a result, the state of each object is as shown in FIG. 29, for example.

  FIG. 29 is a fifth diagram illustrating an example of the state of each object. As shown in the figure, the reference relationship from the linked collection object to the identification element collection object and the reference element collection object is formed by executing step S318. Note that, in the state shown in FIG. 29, a reference to the linked collection object is returned from the linked collection object generation unit 13 to the Department object.

  Subsequently, the Department object assigns a reference to the linked collection object to the employees field that is a reference element collection field (S319). As a result, the state of each object is as described in FIG. A reference to the linked collection object in the state shown in FIG. 8 is returned to the application program 17 as a return value of getEmployees called in step S309. That is, steps S310 to S319 are processes defined in the description 115a in FIG.

  Subsequently, the application program 17 requests the O / R mapper access unit 14 to commit the transaction (S320). The O / R mapper access unit 14 requests the O / R mapper unit 15a and the O / R mapper unit 15b to commit a transaction to each of them (S321 and S322).

  As described above, even when the reference element collection field of the Department object is excluded from the target of persistence, the reference relationship between the Department object and the Employee object can be restored based on the identification element collection field.

  Next, a processing procedure executed at the dirty check will be described. The processing procedure executed at the time of the dirty check is a processing procedure executed when a change content for the Department object or the Employee object is reflected in the data store 16a or the data store 16b.

  30 and 31 are sequence diagrams for explaining an example of a processing procedure executed at the time of the dirty check. FIG. 30 and FIG. 31 illustrate a processing procedure related to one scenario in which a dirty check is performed, and does not indicate that the dirty check is always executed by the processing procedure. Before the processing procedure shown in FIG. 30, the processing procedure (S301 to S319) described in FIG. 25 and FIG. 26 is executed, and the linked recovery object in the state shown in FIG. Suppose that

  Subsequent to step S319, the application program 17 substitutes the linked collection object returned as a return value of the getEmployees method of the Department object for a local variable (S420). As a result, the state of each object shown in FIG. 8 changes to that shown in FIG.

  FIG. 32 is a sixth diagram illustrating an example of the state of each object. In the figure, a state in which the reference to the linked collection object is assigned to the local variable is shown.

  Note that the application program 17 (developer) is not aware that the return value of the getEmployees method is a linked collection object. That is, the getEmployees method is a getter of the reference element collection field in the Department object. Therefore, the application program 17 (the developer) handles the return value of the getEmployees method as a reference to the reference element collection object.

  Subsequently, the application program 17 newly generates an Employee object (S421). Subsequently, the application program 17 designates a local variable to which a reference to the generated Employee object is assigned, and requests the linked collection object to add the Employee object (S422).

  Subsequently, the linked collection object adds a reference to the Employee object stored in the local variable specified in the addition request as an element of the reference element collection object set in the vals field of the linked collection object ( S423). Subsequently, the linked collection object adds the value of the id field of the employee object as an element of the identification element collection object set in the ids field of the linked collection object (S424).

  As a result of the above processing, the state of each object changes from that shown in FIG. 32 to that shown in FIG.

  FIG. 33 is a seventh diagram illustrating an example of the state of each object. In the drawing, a reference to the newly generated Employee object whose id field value is “500” is added to the element of the reference element collection object. In addition, a character string object indicating the value of the id field of the Employee object is added as an element of the identification element collection object. As a result, the consistency between the reference element collection object and the identification element collection object is maintained.

  Subsequently, the application program 17 requests the O / R mapper access unit 14 to make the newly generated Employee object permanent (FIG. 31: S425). For example, the O / R mapper access unit 14 refers to the object arrangement definition storage unit 22 and determines that the O / R mapper unit 15 corresponding to the Employee object is the O / R mapper unit 15b. Therefore, the O / R mapper access unit 14 requests the O / R mapper unit 15b to make the Employee object permanent (S426).

  Subsequently, the application program 17 requests the O / R mapper access unit 14 to commit the transaction (S427). The O / R mapper access unit 14 requests the O / R mapper unit 15a and the O / R mapper unit 15b to commit the transaction to each of them (S428 and S430).

  At this time, when the O / R mapper unit 15a executes a commit, a difference from the contents of the data store 16a is detected with respect to the employeeIds field of the Department object. That is, the value (“500”) of the id field newly added to the identification element collection object set in the employeeIds field is detected as a difference. Therefore, the O / R mapper unit 15a reflects the difference in the data store 16a. That is, in the data store 16a, the value (“500”) as the difference is added to the employeesIds item of the record whose id item value is “HR”. Such processing by the O / R mapper unit 15a can be realized by a standard function of the O / R mapper unit 15 called dirty check.

  As a result, the persistence state of the Department object and the Employee object changes from the one shown in FIG. 24 to the one shown in FIG. 34, for example.

  FIG. 34 is a diagram illustrating an example of the persistence state of the Department object and the Employee object after the dirty check.

  In the figure, “500” is added to the “employeesIds” item of the record corresponding to the Department object whose id value is “HR” in the data store 16a. In addition, a record corresponding to an Employee object whose id field value is “500” is added to the data store 16b.

  As described above, in the present embodiment, the consistency between the reference element collection object and the identification element collection object can be maintained by using the linked collection object as the operation target of the application program 17 instead of the reference element collection object. it can. As a result, the dirty check can function effectively.

  In this embodiment, for the sake of convenience, a one-to-many reference relationship from a Department object to an Employee object has been described. It can also be applied to the reference relationship.

  As described above, according to the present embodiment, reference matching is performed on object groups having different reference destinations such as one-way one-to-many, bidirectional one-to-many, or bidirectional many-to-many. Persistence can be performed without violating the sex constraint and maintaining the reference relationship. In other words, the reference relationship between objects can be made persistent across a plurality of data stores.

  In addition, regarding the set of the reference element collection field of the reference source class (for example, Department class) that refers to the object of the reference class (for example, the Employee class), the consistency between the reference element collection field and the identification element collection field is The class definition file is automatically changed so that it is maintained. Therefore, it is possible to avoid inconsistency between the reference element collection field and the identification element collection field in response to the call to the setter.

  Also, a linked collection object is introduced to maintain the consistency between the reference element collection field and the identification element collection field, and the linked collection object is returned in the getter of the reference element collection field. Then, the linked collection object refers to the reference source object reference element collection object and the identification element collection object. This means that the linked collection object substantially refers to the reference collection field and the identification element collection field of the reference source object. Further, the linked collection object implements the same interface (List interface) as the reference element collection object, and adds or deletes an object through the interface to the reference element collection object and the identification element collection object of the reference source object. reflect. That is, addition or deletion of an object through the interface is reflected in the reference element collection field and the identification element collection field of the reference source object. Therefore, even if the return value of the getter of the reference element collection field is assigned to a local variable or the like, a change request regarding the reference element collection object made through the local variable is sent to the reference element of the reference source object. It can be reflected in both the collection field and the child identification element collection field.

  In the present embodiment, an example is shown in which the reference to the linked collection object is set (assigned) to the reference element collection field of the reference source object (Department object). However, the reference to the linked collection object is not necessarily set in the reference element collection field. For example, a field in which a reference to a linked collection object is set (hereinafter referred to as “linked collection field”) may be added separately to the class of the reference source object. In this case, in the getter of the reference element collection field, the linked collection object set in the linked collection field may be returned.

  However, when a linked collection field is provided, a process for adding a linked collection field is required for changing the class definition file. In addition to the reference element collection field, it is necessary to remove the linked collection field from the persistence target. That is, there is an inconvenience that the number of changes to the class definition file increases. Another disadvantage is that the data size of the object increases by the data size of the linked collection field.

  On the other hand, in the embodiment in which the reference to the linked collection object is set in the reference element collection field as in the present embodiment, there is no inconvenience as described above. Therefore, in this respect, it can be said that the form in which the reference to the linked collection object is set in the reference element collection field is excellent.

  Further, as another effect obtained by the present embodiment, it is possible to positively reconfigure a plurality of data stores by making it possible to perpetuate a reference relationship across a plurality of data stores. Therefore, it can be expected that the work for measuring the performance of each configuration and finding the optimal configuration will be facilitated.

  Further, the application range of non-relevant data stores such as KVS that can be used like a relational data store such as RDB even if it is a non-relevant data store that cannot originally manage a reference relationship can be expanded. We can expect to contribute to

  In the present embodiment, the Department class is an example of a first class. The Employee class is an example of a second class. The class definition file is an example of first class definition information. The reference attribute exclusion unit 122 is an example of an exclusion unit. The identification attribute adding unit 121 is an example of an adding unit. The reference attribute setting method changing unit 123 is an example of a first changing unit. The reference attribute acquisition method changing unit 124 is an example of a second changing unit. A linked collection object is an example of a linked object.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

Regarding the above description, the following items are further disclosed.
(Appendix 1)
An exclusion unit that changes the definition information of the first class so that the first attribute that is a set of objects of the second class among the attributes of the first class is excluded from the persistence target;
An adding unit that adds a second attribute that is a set of identification attribute values of the second class of objects to the definition information;
For the processing according to the setting request for the set of objects of the second class for the first attribute, the set of values of the identification attributes of the objects of the second class included in the set is set to the second A first change unit that changes the definition information so as to set the attribute of
For the process according to the acquisition request for the first attribute, the definition information is changed so as to return a linked object that reflects the change request for the first attribute in the first attribute and the second attribute. An information processing apparatus having a second changing unit.
(Appendix 2)
The first changing unit is configured to process the set and the second class of objects included in the set for the processing in response to the setting request for the set of the second class of objects for the first attribute. The set of identification attribute values is referred to by the linked object, and the definition information is changed to set the linked object as the first attribute,
The information processing apparatus according to appendix 1, wherein the linked object changes a set of objects of the second class referenced by the linked object and a set of values of the identification attribute in response to a change request for the first attribute.
(Appendix 3)
When the linked object is set in the first attribute, the second changing unit returns the linked object for the process according to the acquisition request for the first attribute, When the linked object is not set in the attribute, obtain a set of objects of the second class corresponding to the set of identification attribute values set in the second attribute from the persistence destination, The information processing apparatus according to supplementary note 2, wherein the definition information is changed so that the acquired linked object is referred to by the linked object and the linked object is returned.
(Appendix 4)
Among the attributes of the first class, change the definition information of the first class so that the first attribute that is a set of objects of the second class is excluded from the persistence target,
Adding a second attribute that is a set of identification attribute values of the second class of objects to the definition information;
For the processing according to the setting request for the set of objects of the second class for the first attribute, the set of values of the identification attributes of the objects of the second class included in the set is set to the second Change the definition information so that it is set to the attribute of
For the process according to the acquisition request for the first attribute, the definition information is changed so as to return a linked object that reflects the change request for the first attribute in the first attribute and the second attribute. Information processing method in which a computer executes processing to be performed.
(Appendix 5)
The processing for changing the processing in response to the setting request for the set of the second class of objects for the first attribute is the identification attribute of the set and the second class of objects included in the set. The definition information is changed so that the linked object is referred to the set of values, and the linked object is set as the first attribute.
The information processing method according to appendix 4, wherein the linked object changes a set of objects of the second class referenced by the linked object and a set of values of the identification attribute in response to a change request for the first attribute.
(Appendix 6)
In the process of changing the process according to the acquisition request for the first attribute, when the linked object is set in the first attribute, the linked object is returned and the linked to the first attribute. If no object is set, a set of objects of the second class corresponding to a set of values of the identification attribute set in the second attribute is acquired from the persistence destination, and the acquired set The information processing method according to appendix 5, wherein the definition information is changed so that a set is referred to by the linked object and the linked object is returned.
(Appendix 7)
Among the attributes of the first class, change the definition information of the first class so that the first attribute that is a set of objects of the second class is excluded from the persistence target,
Adding a second attribute that is a set of identification attribute values of the second class of objects to the definition information;
For the processing according to the setting request for the set of objects of the second class for the first attribute, the set of values of the identification attributes of the objects of the second class included in the set is set to the second Change the definition information so that it is set to the attribute of
For the process according to the acquisition request for the first attribute, the definition information is changed so as to return a linked object that reflects the change request for the first attribute in the first attribute and the second attribute. A program that causes a computer to execute processing to be performed.
(Appendix 8)
The processing for changing the processing in response to the setting request for the set of the second class of objects for the first attribute is the identification attribute of the set and the second class of objects included in the set. The definition information is changed so that the linked object is referred to the set of values, and the linked object is set as the first attribute.
The program according to appendix 7, wherein the linked object changes a set of objects of the second class and a set of values of the identification attribute referred to by the linked object in response to a change request for the first attribute.
(Appendix 9)
In the process of changing the process according to the acquisition request for the first attribute, when the linked object is set in the first attribute, the linked object is returned and the linked to the first attribute. If no object is set, a set of objects of the second class corresponding to a set of values of the identification attribute set in the second attribute is acquired from the persistence destination, and the acquired set The program according to appendix 8, wherein the definition information is changed so that the linked object is referred to and the linked object is returned.

DESCRIPTION OF SYMBOLS 10 Information processing apparatus 11 Change object selection part 12 Class definition change part 13 Linked collection object generation part 14 O / R mapper access part 15a O / R mapper part 15b O / R mapper part 16a Data store 16b Data store 21 Class definition file storage Unit 22 Object arrangement definition storage unit 100 Drive device 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 CPU
105 Interface device 121 Identification attribute adding unit 122 Reference attribute excluding unit 123 Reference attribute setting method changing unit 124 Reference attribute obtaining method changing unit B bus

Claims (5)

An exclusion unit that changes the definition information of the first class so that the first attribute that is a set of objects of the second class among the attributes of the first class is excluded from the persistence target;
An adding unit that adds a second attribute that is a set of identification attribute values of the second class of objects to the definition information;
For the processing according to the setting request for the set of objects of the second class for the first attribute, the set of values of the identification attributes of the objects of the second class included in the set is set to the second A first change unit that changes the definition information so as to set the attribute of
For the process according to the acquisition request for the first attribute, the definition information is changed so as to return a linked object that reflects the change request for the first attribute in the first attribute and the second attribute. An information processing apparatus having a second changing unit. The first changing unit is configured to process the set and the second class of objects included in the set for the processing in response to the setting request for the set of the second class of objects for the first attribute. The set of identification attribute values is referred to by the linked object, and the definition information is changed to set the linked object as the first attribute,
The information processing apparatus according to claim 1, wherein the linked object changes a set of objects of the second class and a set of values of the identification attribute referred to by the linked object in response to a change request for the first attribute. .   When the linked object is set in the first attribute, the second changing unit returns the linked object for the process according to the acquisition request for the first attribute, When the linked object is not set in the attribute, obtain a set of objects of the second class corresponding to the set of identification attribute values set in the second attribute from the persistence destination, The information processing apparatus according to claim 2, wherein the definition information is changed so that the acquired linked object is referred to and the linked object is returned. Among the attributes of the first class, change the definition information of the first class so that the first attribute that is a set of objects of the second class is excluded from the persistence target,
Adding a second attribute that is a set of identification attribute values of the second class of objects to the definition information;
For the processing according to the setting request for the set of objects of the second class for the first attribute, the set of values of the identification attributes of the objects of the second class included in the set is set to the second Change the definition information so that it is set to the attribute of
For the process according to the acquisition request for the first attribute, the definition information is changed so as to return a linked object that reflects the change request for the first attribute in the first attribute and the second attribute. Information processing method in which a computer executes processing to be performed. Among the attributes of the first class, change the definition information of the first class so that the first attribute that is a set of objects of the second class is excluded from the persistence target,
Adding a second attribute that is a set of identification attribute values of the second class of objects to the definition information;
For the processing according to the setting request for the set of objects of the second class for the first attribute, the set of values of the identification attributes of the objects of the second class included in the set is set to the second Change the definition information so that it is set to the attribute of
For the process according to the acquisition request for the first attribute, the definition information is changed so as to return a linked object that reflects the change request for the first attribute in the first attribute and the second attribute. A program that causes a computer to execute processing to be performed.

Images