JP5673246B2 - Data store control device, data store control program, and data store control method - Google Patents

Description

  The present invention relates to a data store control device, a data store control program, and a data store control method.

  Conventionally, RDB (Relational Database) that stores data in units of tables and executes data operations using SQL (Structured Query Language) statements has been used. For example, in Java (registered trademark), JPA (Java (registered trademark) Persistence Application Programming Interface) is provided as a framework for handling RDB.

  FIG. 17 is a diagram for explaining table creation by Java (registered trademark). As shown in FIG. 17, a class to be persisted on a Java (registered trademark) program corresponds to one table on the RDB, each object corresponds to each row of the table on the RDB, and each field is a table on the RDB. Corresponds to the item. That is, the Employee class shown in FIG. 17 defines an employee table on the RDB. Further, “id”, “name”, and “position” defined in the Employee class correspond to columns “employee ID”, “name”, and “position” on the employee table, respectively.

  Next, an example of relating between tables using the properties of RDB will be described. FIG. 18 is a diagram illustrating an example of creating a table having a reference relationship. As shown in FIG. 18, on the Java (registered trademark) program, an Employee class that defines “Employee ID”, “Name”, and “Job title”, and a Department class that defines “Department ID” and “Department name” Executes the class diagram with the reference relationship. In this case, the data store accessor stores the employee table formed from “Employee ID”, “Name”, “Position”, “Department ID <FK (foreign key)>”, “Department ID” and “Department name”. Create a department table on the RDB. That is, “department ID <FK>” of the employee table is defined to refer to “department ID” of the department table, and it is defined that the employee table and the department table are in a reference relationship. As described above, in Java (registered trademark), various tables that can be managed by RDB using JPA are created.

  In recent years, with the spread of cloud computing, the use of new data stores such as distributed KVS (Key-Value Store) has become widespread in addition to RDB that has been widely used. Distributed KVS does not have a function to immediately guarantee consistency of data among servers, but it has scalability by data management on multiple servers and high availability that allows services to continue even if some servers are down. It has a lower cost than RDB. For this reason, a system is constructed using both an RDB that can guarantee data consistency immediately but has a high cost, and a distributed KVS that is inexpensive and highly available.

  As described above, in a system using a data store with a different management method, a technique for linking data stores, a technique for optimizing reference access of the data store, and the like are used. For example, as a technology for linking data stores with different management methods, a basic operation common to each data store is defined as common SQL, and a technology that uses a unique language for operations unique to each data store is used. Yes. Also, as a technology for optimizing reference access, the number of accesses to the data store is reduced based on the dependency of the access key of the finder method in Java (registered trademark) and the access status of the getter method and setter method. Has been implemented.

JP 2002-297418 A JP 2001-51879 A JP 2007-66017 A

  However, in the conventional technology, when data is registered across data stores with different management methods, the data stores are associated with each other by using an external key. There was a problem that it could not be executed efficiently.

  Using JPA as an example, JPA defines in the program that creates a table in RDB that the RDB data refers to the distributed KVS using a foreign key. That is, when dealing with a plurality of data stores in JPA, external references between tables having relations across the data stores are implemented on the application side. For this reason, maintenance other than the database will be performed, such as modifying the application in accordance with the data arrangement change, and the range of maintenance will be widened, so the maintenance work of the database cannot be performed easily and is efficient. It is hard to say that there is.

  It is an object of the first aspect to provide a data store control device, a data store control program, and a data store control method that make data store maintenance work more efficient.

  In the first proposal, the data store control device refers to a second data store having a different management method in the first data store among the persistence targets defined by the program describing the process for the first data store. It has the exclusion part which excludes the 1st attribute which shows from permanent object. The data store control device includes an adding unit that adds a second attribute that identifies a reference destination of the program as a persistence target to the program. The data store control device includes a definition unit that defines specific information for specifying the reference destination in the program as definition information corresponding to the added second attribute. The data store control device includes a changing unit that changes definition information corresponding to the first attribute defined in the program to information indicating execution of a process acquired from the second data store using the specific information. Have.

  Data store maintenance work can be streamlined.

FIG. 1 is a diagram illustrating an overall configuration of a system including an application server according to the first embodiment. FIG. 2 is a diagram illustrating a reference relationship between tables. FIG. 3 is a block diagram illustrating the configuration of the application server according to the second embodiment. FIG. 4 is a diagram illustrating an example of a setting file stored in the setting file table. FIG. 5 is a diagram illustrating an example in which both the identification attribute and the relation are set. FIG. 6 is a diagram illustrating an example in which a value is set in the identification attribute but no relation is set. FIG. 7 is a diagram illustrating an example in which no value is set for the identification attribute but a relation is set. FIG. 8 is a diagram illustrating an example in which neither the identification attribute nor the relation is set. FIG. 9 is a diagram illustrating an example of a program executed by the data access unit. FIG. 10 is a diagram illustrating an implementation example of acquiring the transaction instance illustrated in FIG. 9. FIG. 11 is a diagram illustrating an example of the Employee class before conversion. FIG. 12 is a diagram illustrating an example in which the identification attribute is described by excluding the relation from the persistence target. FIG. 13 is a diagram illustrating an example of the converted Employee class. FIG. 14 is a flowchart showing the flow of application conversion processing. FIG. 15 is a diagram illustrating an example of a table created by executing a program after class conversion. FIG. 16 is a diagram illustrating a hardware configuration example of a computer that executes a data store control program. FIG. 17 is a diagram for explaining table creation by Java (registered trademark). FIG. 18 is a diagram illustrating an example of creating a table having a reference relationship.

  Embodiments of a data store control device, a data store control program, and a data store control method disclosed in the present application will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

  FIG. 1 is a diagram illustrating an overall configuration of a system including an application server according to the first embodiment. As shown in FIG. 1, in this system, a data store machine 1, a data store machine 2, and an application server 3 are connected via a network. This system realizes cloud computing in which the application server 3 executes each process using data stored in the data store machine 1 or the data store machine 2.

  The data store machine 1 is a server that stores data using an RDB (Relational Database). The data store machine 2 is a server that stores data using KVS (Key-Value Store).

  The application server 3 includes an excluding unit 3a, an adding unit 3b, a defining unit 3c, and a changing unit 3d. For the data store machine 1 or the data store machine 2, table creation, data registration, data update, data deletion, etc. The server to execute.

  For example, an example will be described in which the application server 3 creates a table in which the data store machine 1 and the data store machine 2 have a reference relationship using JPA (Java (registered trademark) Persistence Application Programming Interface).

  Here, an example in which tables in the data store machine 1 and the data store machine 2 are in a reference relationship will be described first. FIG. 2 is a diagram illustrating a reference relationship between tables. As shown in Fig. 2, RDB has an employee table with records formed from "Employee ID, Title, Name, Department ID", and KVS has a record formed from "Department ID, Department". Have an employee table. In such a situation, the RDB employee table and the KVS department table are related by “department ID”, and the record of the related department table can be acquired from the employee table. Such a relationship is called a reference relationship.

  Next, it is assumed that the application server 3 uses the JPA to execute a first program that generates a table for referring to the data store machine 2 in the data store machine 1. In this case, the exclusion unit 3a sets the first attribute indicating that the table of the data store machine 1 refers to another table among the persistence targets defined for the table to be created in the data store machine 1 as the program persistence target. Exclude from Subsequently, the adding unit 3b adds a second attribute for identifying the table of the data store 2 from the table of the data store 1 to the program as a permanent object. Then, the definition unit 3c includes, in the program, identification information that identifies the reference destination as definition information corresponding to the added second attribute. Furthermore, the changing unit 3d changes the definition information corresponding to the first attribute defined in the program to information indicating execution of the process acquired from the data store machine 2 using the specific information.

  Thus, even when a program in which a foreign key is defined is executed, the application server 3 can rewrite the program contents so that databases with different management methods are connected without using the foreign key. Therefore, even if the data arrangement of the data store machine 1 or the data store machine 2 is changed, it is not necessary to modify the program. Therefore, even if the data is registered across data stores with different management methods, the data store Maintenance work can be performed efficiently.

  Next, an application server according to the second embodiment will be described. Here, the configuration of the application server, a specific example, the flow of processing, and the effects of the second embodiment will be described. Since the system configuration is the same as that shown in FIG. 1, the system configuration and the application server are omitted except for the system configuration. In the second embodiment, an application described by a program using JPA will be described as an example.

Application server configuration
FIG. 3 is a block diagram illustrating the configuration of the application server according to the second embodiment. As shown in FIG. 3, the application server 10 includes a pre-conversion application table 11, a post-conversion application table 12, a setting file table 13, a pre-conversion execution unit 14, a persistent class conversion unit 15, a post-conversion execution unit 16, and data access. Part 17 and data accessor 18.

  The pre-conversion application table 11, the post-conversion application table 12, and the setting file table 13 are provided in a semiconductor memory device, a hard disk, or the like. Each control unit other than the above table is executed by a CPU (Central Processing Unit) or the like.

  The pre-conversion application table 11 stores an application generated by a developer. For example, the pre-conversion application table 11 stores an application that executes processing such as table creation, data registration, data update, and data deletion for the data store machine 1 that manages data in the RDB. In addition, the pre-conversion application table 11 stores an application that executes processing such as table creation, data registration, data update, and data deletion for the data store machine 2 that manages data with KVS.

  As another example, the pre-conversion application table 11 is a data process for the data store machine 1 and stores an application in which a foreign key that refers to the table of the data store machine 2 is set. Similarly, the pre-conversion application table 11 is a data process for the data store machine 2 and stores an application in which an external key that refers to the table of the data store machine 1 is set. The application stored here is stored by an application developer, an administrator of the application server 10, or the like. The application 11 before conversion can also store the generated date and time, the number of updates, etc. in association with the application before conversion.

  The post-conversion application table 12 stores the application converted by the persistent class conversion unit 15. The application stored here is stored and updated by the changing unit 15d of the persistence class converting unit 15 described later. The converted application table 12 can also store the date and time of conversion, the number of conversions, and the like in association with the converted application.

  The setting file table 13 stores a setting file of a class arranged for each data store. FIG. 4 is a diagram illustrating an example of a setting file stored in the setting file table 13. As shown in FIG. 4, the URL (Uniform Resource Locator) is “http // localdomain / RDB” and the data store name “RDB4Update” managed by “RDB” is set as the data store. Then, “Entity Class = Department” is set as the class of the data store. Similarly, as the data store, the URL is “http // localdomain / KVS”, and the data store name “KVS” managed by “KVS” is set. “Entity Class = Employee” is set as the class of the data store. That is, FIG. 4 shows that the Department class is arranged in the RDB and that the Employee class is arranged in the KVS is managed by the map.

  When the pre-conversion execution unit 14 receives an instruction operation from an administrator or the like, the pre-conversion execution unit 14 reads the designated application from the pre-conversion application table 11 and executes it. Note that the pre-conversion execution unit 14 can accept an instruction operation from an input device such as a mouse, an output device such as a touch panel, or the like, and can also accept an instruction operation from another server via a network. In the second embodiment, it is assumed that the pre-conversion execution unit 14 performs data processing for the data store machine 1 and executes an application A in which a foreign key that refers to the table of the data store machine 2 is set.

  The persistence class converting unit 15 includes an excluding unit 15a, an adding unit 15b, a defining unit 15c, and a changing unit 15d, which converts an application executed by the pre-conversion execution unit 14 and converts the application table 12 after conversion. To store.

  The exclusion unit 15a excludes a relation attribute representing a reference relationship between classes of the persistence class from the persistence target. For example, in the application A that creates a table in the data store machine 1, the exclusion unit 15 a excludes the relation attribute indicating that the application A refers to the data store machine 2 having a management method different from that of the data store machine 1 from the persistence target. To do.

  That is, the excluding unit 15a specifies the reference object described by the annotation representing the relation in the class 1 in the application A as the relation attribute, and excludes the specified object from the persistence target. In other words, the excluding unit 15 a excludes the relation attribute from the management target of the data store machine 1.

  The adding unit 15b adds an identification attribute for identifying the reference destination of class 1 to class 1 of application A as a persistence target. If it demonstrates using the said example, the addition part 15b will set the identification attribute which identifies the reference destination designated by the excluded relation with respect to the application A from which the relation was excluded from the management object by the exclusion part 15a. Add a new to.

  The definition unit 15c defines specific information for specifying the reference destination in the application A as definition information corresponding to the added identification attribute. If it demonstrates using the said example, the definition part 15c will newly describe the setter method and getter method of an identification attribute with respect to the application A in which the identification attribute was newly described.

  The change unit 15d changes the definition content of the relation attribute defined in the class 1 of the application A to a process of acquiring the reference destination object from the data store machine 2 using the primary key defined by the definition unit 15c. . If it demonstrates using the said example, the change part 15d will correct the setter method and getter method defined with respect to the relation attribute set as a foreign key with respect to the application A in which the identification attribute was newly described. . Then, the changing unit 15d stores the converted application A after conversion in the converted application table 12.

  Here, the definition unit 15c and the change unit 15d execute definition or correction of the setter method and the getter method so that the consistency can be obtained regardless of any of the conditions illustrated in FIGS. FIG. 5 is a diagram illustrating an example in which both the identification attribute and the relation are set. FIG. 6 is a diagram illustrating an example in which a value is set in the identification attribute but no relation is set. FIG. 7 is a diagram illustrating an example in which no value is set for the identification attribute but a relation is set. FIG. 8 is a diagram illustrating an example in which neither the identification attribute nor the relation is set.

  Specifically, FIG. 5 shows that “employee ID = 003, title = general employee, name = Yamada, identification attribute (dep_id) = B001” is set in the application A that defines the Employee table of the data store machine 1. Yes. Furthermore, “department ID = B001, department name = purchasing” is set in the application B that defines the Department table of the data store machine 2 that is the reference destination of the Employee table.

  In FIG. 6, “employee ID = 003, title = general employee, name = Yamada, identification attribute (dep_id) = B001” is set in the application A that defines the Employee table of the data store machine 1. On the other hand, nothing is set in the application B that defines the Department table of the data store machine 2.

  In FIG. 7, “employee ID = 003, title = general employee, name = Yamada, identification attribute (dep_id) = NULL” is set in the application A that defines the Employee table of the data store machine 1. Furthermore, “department ID = B001, department name = purchasing” is set in the application B that defines the Department table of the data store machine 2 that is the reference destination of the Employee table.

  In FIG. 8, “employee ID = 003, title = general employee, name = Yamada, identification attribute (dep_id) = NULL” is set in the application A that defines the Employee table of the data store machine 1. Furthermore, “department ID = B001, department name = purchasing” is set in the application B that defines the Department table of the data store machine 2, but the Employee table and the Department table are not in a reference relationship.

  Therefore, the definition unit 15c and the change unit 15d generate setter methods and getter methods that can handle various situations so that the table configuration or the like does not change before and after the conversion of the application A. Note that description with a specific example will be described later, and is omitted here.

  Returning to FIG. 3, the post-conversion execution unit 16 reads the converted application from the post-conversion application table 12 and executes it. The post-conversion execution unit 16 outputs a table creation request for the data store machine 1 to the data access unit 17 when executing the converted application A.

  The data access unit 17 generates a MetaEntityManager that defines a data store to be accessed for each class based on the setting file for each class stored in the setting file table 13. For example, the data access unit 17 holds the accessor corresponding to the persistence class and the placement destination data store in a map. Subsequently, the data access unit 17 takes in the data store and the list file of the classes to be arranged from the setting file table 13 and sets the EntityManager that is the data accessor of the arrangement destination data store in the map using the class as a key. . The data access unit 17 includes a creation unit 17a, an update unit 17b, a reference unit 17c, and a transaction management unit 17d, and executes processing according to these and the program shown in FIG. FIG. 9 is a diagram illustrating an example of a program executed by the data access unit.

  When the creation unit 17a receives a Create message from the application executed by the post-conversion execution unit 16, the creation unit 17a identifies a data accessor corresponding to the class of the application. Then, the creation unit 17a transmits a Create message to the data accessor 18 that executes the specified data accessor. For example, when the creation unit 17a receives a Create message for the data store machine 1, the creation unit 17a transmits the Create message to the rdb_EntityManager. Further, when the creation unit 17a receives a Create message to the data store machine 2, the creation unit 17a transmits the Create message to kvs_EntityManager.

  The update unit 17b associates the persist function of JPA with a plurality of data stores, and executes the update method shown in FIG. For example, when the application executed by the post-conversion execution unit 16 executes the persist function, the update unit 17b specifies the data accessor corresponding to the execution application class of the persist function. Then, the update unit 17b transmits a process execution request to the data accessor 18 that executes the specified data accessor.

  As an example, the update unit 17b instructs the rdb_EntityManager to execute update processing when the Entity placement destination in the persist function is the data store machine 1. In addition, the update unit 17b instructs kvs_EntityManager to execute update processing when the Entity placement destination in the persist function is the data store machine 2.

  The reference unit 17c associates a JPA find function with a plurality of data stores, and executes the reference method shown in FIG. For example, when the application executed by the post-conversion execution unit 16 executes the find function, the reference unit 17c specifies the data accessor corresponding to the execution application class of the find function. Then, the reference unit 17c transmits a process execution request to the data accessor 18 that executes the specified data accessor.

  For example, the reference unit 17c instructs the rdb_EntityManager to execute the reference process when the class placement destination in the find function is the data store machine 1. Further, the reference unit 17c instructs kvs_EntityManager to execute the reference process when the class arrangement destination in the find function is the data store machine 2.

  The transaction management unit 17d associates getTransaction in JPA with a plurality of data stores, and executes transaction instance acquisition shown in FIG. The transaction management unit 17d implements the MetaTransaction class for managing a plurality of transactions illustrated in FIG. 10, and manages each transaction so that transactions to each data store machine are executed and terminated simultaneously. FIG. 10 is a diagram illustrating an implementation example of acquiring the transaction instance illustrated in FIG. 9.

  The data accessor 18 holds an accessor corresponding to each data store machine, and distributes various processes input from the data access unit 17 to the corresponding accessor. Then, the data accessor 18 performs processing on the data store using each accessor. For example, when the data accessor 18 receives a table creation process for the data store machine 1, in other words, when an execution request for the Employee class is received, the data accessor 18 uses the accessor corresponding to the data store machine 1 to perform the table creation process. Run to 1. Similarly, when the data accessor 18 receives a table creation process to the data store machine 2, in other words, when an execution request for the Department class is received, the data accessor 18 uses the accessor corresponding to the data store machine 2 to perform the table creation process. Run on machine 2.

[Concrete example]
Next, a specific example of program conversion will be described with reference to FIGS. FIG. 11 is a diagram illustrating an example of the Employee class before conversion, FIG. 12 is a diagram illustrating an example in which the identification attribute is described by excluding the relation from the persistence target, and FIG. 13 is a diagram illustrating the Employee after conversion. It is a figure which shows the example of a class. Here, a program written in JPA will be described as an example.

  The pre-conversion execution unit 14 executes an application having the program shown in FIG. Then, the exclusion unit 15a changes “private Department dep;” described in the annotation “@OneToOne” illustrated in FIG. 11A to “private transient Department dep;” as illustrated in FIG. As a result, “Department dep” is excluded from the persistence target and excluded from the management target of each data store machine.

  As illustrated in FIG. 12, the adding unit 15 b newly describes “private String dep_id” that has not been described in the state of FIG. 11 in the program. As a result, “dep_id” of the String type is newly defined as a permanent object as an identification attribute.

  Then, the definition unit 15c newly defines a getter method having the identification attribute “dep_id” in the program, as illustrated in FIG. Specifically, if a value is set in the relation attribute “this.dep” in the Employee class, the definition unit 15c returns the value of the identification attribute of the relation destination, and the relation attribute “this.dep” in the class. If no value is set in, the value of the identification attribute is returned. That is, when a value is set in the Relation class, the definition unit 15c returns the value of the identification attribute set in the Depatment class, in other words, the primary key of the reference object. Further, the definition unit 15c returns the value of the identification attribute of the Employee class when a value is set in the Department class that is the relation destination.

  In addition, the definition unit 15c newly defines a setter method of the identification attribute “dep_id” in the program as illustrated in FIG. Specifically, the definition unit 15 c sets the value of “this.dep_id” to the identification attribute “dep_id”.

  Subsequently, the changing unit 15d changes the gettr method of the relation attribute “dep” already defined in the Employee class, as illustrated in FIG. Specifically, the changing unit 15d identifies the relation attribute “this.dep” in the Employee class if null is set and the identification attribute “this.dep_id” in the Employee class is not set to null. Get an object from the data store using attributes and respond. The change unit 15d determines that the relation attribute “this.dep” in the Employee class is not set to null or the identification attribute “this.dep_id” in the Employee class is set to null. Returns the value of “dep”.

  That is, the changing unit 15d acquires a reference destination object via the data access unit 17 or the data list accessor 18 if the relation attribute in the class is null and the identification attribute in the class is not null. Change the getter method.

  Further, the changing unit 15d changes the settr method of the relation attribute “dep” already defined in the Employee class, as shown in FIG. Specifically, the changing unit 15d sets the value of the relation attribute “dep” in the relation attribute “this.dep” in the Employee class. Then, the changing unit 15d sets null to the identification attribute “dep_id” if the set value is null. In addition, if the set value is not null, the changing unit 15d sets the ID of the relation attribute to the identification attribute “dep_id”.

  That is, the change unit 15d sets the primary key of the reference destination object to the identification attribute if the reference attribute is not null as a result of setting the reference destination object to the relation attribute, and sets the identification attribute to null if it is null. Change the setter method to

  The converted application converted in this way is executed by the post-conversion execution unit 16. Then, the creation unit 17 a of the data access unit 17 analyzes the executed converted application and outputs a table creation process for the data store machine 1 to the data accessor 18. The data accessor 18 creates a table in the data storage machine 1 via a data accessor corresponding to the data store machine 1.

[Process flow]
Next, the flow of application program conversion processing will be described. FIG. 14 is a flowchart showing the flow of application conversion processing.

  As shown in FIG. 14, when the pre-conversion execution unit 14 executes the application before conversion (Yes in S101), the adding unit 15b disconnects the relation of the executed application before conversion and identifies the application before conversion. An attribute is added (S102).

  Subsequently, the definition unit 15c defines the definition contents defining the getter method and the setter method so that the identification attribute added to the application before conversion can be consistent under any condition shown in FIGS. It adds to the application before conversion (S103). Further, the changing unit 15d modifies the getter method and the setter method of the relation attribute already described in the application before conversion so as to be consistent under any conditions shown in FIGS. 5 to 8 (S104).

  By executing the processing so far, the application server 10 can convert the Employee class before conversion shown in FIG. 11 into the Employee class after conversion shown in FIG.

  Thereafter, the data access unit 17 generates a MetaEntityManager that defines a data store to be accessed for each class, based on the setting file for each class stored in the setting file table 13 (S105). At this time, the data access unit 17 also generates a transaction instance to be executed by the transaction management unit 17d. By this processing, the application server 10 generates the MetaEntityManager shown in FIG. 9 and the transaction instance shown in FIG. 10 based on the setting file shown in FIG.

  Then, the post-conversion execution unit 16 executes the post-conversion application converted by the processes of S101 to S104 (S106). At this time, the data accessor 18 distributes various processes input from the data access unit 17 to the accessors corresponding to the respective data store machines, and executes the processes on the data store using the respective accessors. Further, the transaction management unit 17d controls based on the MetaTransaction class so that executed transactions are simultaneously executed and simultaneously ended.

[Effects of Example 2]
According to the second embodiment, data registration is possible even if there is a reference relationship across data stores, and the arrangement of data can be changed without modifying the source code. When creating a table in each data store, the relation is not set as a foreign key, and the table can be created.

  FIG. 15 is a diagram illustrating an example of a table created by executing a program after class conversion. As shown in the left diagram of FIG. 15, when the Employee class having the relation to the Department class is executed, the application server 10 excludes the relation that the Employee class has from being a permanent object, and is an identification attribute that is a new attribute. Define “dep_id”.

  The application server 10 generates an employee table of “employee ID, title, name, dep_id” in the data store machine 1 by executing the converted class as shown in the left diagram of FIG. At this time, the application server 10 acquires and stores the department ID of the department table “department ID, department name” generated in the data store machine 2 by another class in “dep_id” of the employee table. As a result, the application server 10 can maintain the reference relationship without setting an external key in the employee table even when the employee table has a relationship of referring to the department table.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above. Therefore, different embodiments will be described below.

(Data store type)
In the first and second embodiments, the example in which the employee table managed by the RDB refers to the department table managed by the KVS has been described. However, the present invention is not limited to this. For example, the target DB type and reference relationship can be arbitrarily set and changed. Moreover, the name of a table etc. are an illustration to the last, and are not limited to this.

(Processing type)
In the first and second embodiments, the application for executing table creation has been described as an example. However, the present invention is not limited to this. For example, the same processing as in the first and second embodiments can be executed for an application that registers data in a table, an application that updates data in the table, and an application that deletes data from the table. Further, the data access unit 17 can be set so as not to be executed arbitrarily, and a predetermined data access unit can be used.

(Program language)
In the second embodiment and the like, a program using JPA in Java (registered trademark) has been described as an example. However, the present invention is not limited to this, and an arbitrary program such as C language can be used. Even in this case, the same effect as that of the second embodiment can be obtained by executing the same processing as that described in the second embodiment.

(Conversion example)
In the second embodiment, an example in which an application is generated after conversion by adding an identification attribute, a setter method of the identification attribute, and the like to the executed application A and changing the setter method of the original relation attribute will be described. However, the present invention is not limited to this. For example, the conversion process of the second embodiment may be executed on the copied application A that is a copy of the application A before the conversion, and an application of another file is generated by the conversion process of the second embodiment. Also good.

(system)
In addition, among the processes described in the present embodiment, all or a part of the processes described as being automatically performed can be manually performed. Alternatively, all or part of the processing described as being performed manually can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-described document and drawings can be arbitrarily changed unless otherwise specified.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device, for example, integrating the addition unit 15b and the definition unit 15c, is not limited to that illustrated. That is, all or a part of them can be configured to be functionally or physically distributed / integrated in arbitrary units according to various loads or usage conditions. Further, all or any part of each processing function performed in each device is realized by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or hardware by wired logic. Can be realized as

(program)
By the way, the various processes described in the above embodiments can be realized by executing a program prepared in advance on a computer system such as a personal computer or a workstation. Therefore, in the following, an example of a computer that executes a program having the same function as in the above embodiment will be described.

  FIG. 16 is a diagram illustrating a hardware configuration example of a computer that executes a data store control program. As shown in FIG. 16, a computer system 100 is connected to a bus 101 with a CPU 102, an input device 103, an output device 104, a communication interface 105, an HDD (Hard Disk Drive) 106, and a RAM (Random Access Memory) 107.

  The input device 103 is a mouse or a keyboard, the output device 104 is a display or the like, and the communication interface 105 is an interface such as a NIC (Network Interface Card). The HDD 106 stores information stored in each table shown in FIG. 3 together with the data store control program 106a. The ROM 104 is taken as an example of the recording medium, but various programs may be stored in another computer-readable recording medium such as an HDD, RAM, CD-ROM, and read by the computer. Note that a storage medium may be arranged in a remote place, and the computer may acquire and use the program by accessing the storage medium. At that time, the acquired program may be stored in a recording medium of the computer itself and used.

  The CPU 102 operates the data store control process 107a that executes each function described with reference to FIGS. 1 and 3 by reading the data store control program 106a and developing it in the RAM 107. That is, the data store control process 107a performs the same functions as the exclusion unit 3a, the addition unit 3b, the definition unit 3c, and the change unit 3d. Further, the data store control process 107 a can also execute the same functions as the persistent class conversion unit 15 and the data access unit 17. As described above, the computer system 100 operates as an information processing apparatus that executes the address learning method by reading and executing the program.

1 Data store (RDB)
2 Data store (KVS)
3, 10 Application server 3a, 15a Exclusion unit 3b, 15b Addition unit 3c, 15c Definition unit 3d, 15d Change unit 11 Pre-conversion application table 12 Post-conversion application table 13 Setting file table 14 Pre-conversion execution unit 15 Persistent class conversion unit 16 execution unit after conversion 17 data access unit 17a creation unit 17b update unit 17c reference unit 17d transaction management unit 18 data accessor

Claims (7)

A process for the first data store is described with reference to a setting file that defines a table arranged in the first data store and a table arranged in the second data store in which the first data store is managed differently. of persisted object program as defined in the first attribute indicating a reference to the table before Symbol second data store, and to exclude excluding unit from persistent object of the program,
An adder that refers to the configuration file and adds a second attribute that is specified by the first attribute excluded by the excluder and identifies a reference destination of the program as a perpetuating target;
As definition information corresponding to the added second attribute, a definition unit that defines specific information for specifying the reference destination in the program;
The definition information corresponding to the first attribute defined in the program, and having a changing unit for changing the information indicating the execution of the process of acquiring from the second datastores using the specific information Data store controller. Another defined section, as the definition information, wherein the setting function that sets the predetermined value to the second attribute, if the value in the first attribute is set, which describes the process for the second datastores A response function that responds with a value of a second attribute defined in the program and responds with a predetermined value set by the setting function when a value is not set in the first attribute. The data store control device according to claim 1. The changing unit is configured to first attribute sets a predetermined value, the predetermined value is set to set the value of the second attribute if NULL to NULL, the else set predetermined value is NULL first The information defined in the setting function corresponding to the first attribute defined in the program is changed to information indicating execution of the process of setting the identifier of one attribute to the second attribute, and the first attribute value in response to object obtained by using the up Raimariki if not NULL value of is and the second attribute is NULL, the value of the value of the first attribute is not NULL and the second attribute if NULL The information defined in the response function corresponding to the first attribute defined in the program is changed to information indicating execution of processing for responding to the value set in the first attribute. Datastore controller according to Motomeko 1. Based on the configuration file, a generating unit that generates accessing data store accessing each of said tables,
The access execution part which performs access with respect to the said 1st data store or the said 2nd data store using the accessor for every said produced | generated data store is further characterized by the above-mentioned. The data store control device according to claim 1.   5. The data store control device according to claim 4, wherein the access execution unit starts and ends a plurality of accesses to the first data store or the second data store at the same time. On the computer,
A process for the first data store is described with reference to a setting file that defines a table arranged in the first data store and a table arranged in the second data store in which the first data store is managed differently. of persisted object program as defined in the first attribute indicating a reference to the table before Symbol second data store, excluded from persisting object of the program,
Referring to the configuration file , adding a second attribute that is specified by the excluded first attribute and that identifies the reference destination of the program as a perpetuating target, to the program;
As the definition information corresponding to the added second attribute, specific information for specifying the reference destination is defined in the program,
Data, wherein to execute the process of changing the definition information corresponding to the first attribute as defined in the program, the information indicating the execution of the process of acquiring from the second datastores using the specific information Store control program. A control method executed by a computer,
A process for the first data store is described with reference to a setting file that defines a table arranged in the first data store and a table arranged in the second data store in which the first data store is managed differently. of persisted object program as defined in the first attribute indicating a reference to the table before Symbol second data store, excluded from persisting object of the program,
Referring to the configuration file , adding a second attribute that is specified by the excluded first attribute and that identifies the reference destination of the program as a perpetuating target, to the program;
As the definition information corresponding to the added second attribute, specific information for specifying the reference destination is defined in the program,
Data store control method characterized in that to change the definition information corresponding to the first attribute as defined in the program, the information indicating the execution of the process of acquiring from the second datastores using the specific information.

Images