Method for updating code knowledge graph, electronic equipment and readable storage medium

Abstract

The invention discloses a method for updating a code knowledge graph, electronic equipment and a computer readable storage medium, and the method comprises the steps: responding to an updating event triggering operation for the code knowledge graph of a code library, and obtaining a first Merkel tree corresponding to the triggered code library; the first Merkel tree is compared with a second Merkel tree, a change file is determined, the second Merkel tree is a Merkel tree corresponding to the code library before triggering, and the second Merkel tree is a Merkel tree corresponding to the code library before triggering. Each node value in the first Merkel tree and the second Merkel tree comprises a key formed by a path of a target entry corresponding to a node in the corresponding code library, and a value formed by a content hash value corresponding to the target entry; and updating the code knowledge graph according to the change file.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and particularly to a method, an electronic device, and a readable storage medium for updating a code knowledge graph. Background Art

[0002] With the increasing complexity of software development and maintenance, version control systems are usually selected to manage code, such as Git. Although version control systems have excellent performance in code tracking and version control, they often lack the in-depth understanding and automated analysis capabilities of the relationships between codes. Currently, knowledge graph technology has demonstrated its powerful association analysis and self-learning capabilities in multiple fields. Therefore, by constructing a code knowledge graph, the structure, function, and dependency relationships in the code can be represented in the form of a graph structure. In this way, not only can the process of code management and maintenance be simplified, but also the overall quality and efficiency of software development can be effectively improved.

[0003] However, during the maintenance process of the code knowledge graph, when the original code file is modified, the corresponding code knowledge graph also needs to be modified in a timely manner to ensure its accuracy. Therefore, how to achieve the fast and efficient update of the code knowledge graph is the technical problem to be solved by the present application. Summary of the Invention

[0004] The embodiments of the present application provide a method, an electronic device, and a readable storage medium for updating a code knowledge graph, which can achieve the fast and efficient update of the code knowledge graph.

[0005] To solve the above technical problems, the present application is implemented as follows: In a first aspect, a method for updating a code knowledge graph is provided. The method includes: in response to a trigger operation for an update event of the code knowledge graph of a code library, obtaining a first Merkle tree corresponding to the code library after the trigger; comparing the first Merkle tree with a second Merkle tree to determine a changed file, where the second Merkle tree is the Merkle tree corresponding to the code library before the trigger, and each node value in the first Merkle tree and the second Merkle tree includes: a key composed of the path of the target entry corresponding to the node in the corresponding code library, and a value composed of the content hash value corresponding to the target entry; updating the code knowledge graph according to the changed file.

[0006] In a second aspect, an electronic device is provided, including a processor, a memory, and a program or instruction stored on the memory and executable on the processor. When the program or instruction is executed by the processor, the steps of the method described in the first aspect are implemented.

[0007] In a third aspect, a computer-readable storage medium is provided, on which a program or instructions are stored, and when the program or instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

[0008] In a fourth aspect, a computer program product is provided, the computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program includes program instructions, and when the program instructions are executed by a computer, the computer is caused to implement the steps of the method described in the first aspect when executed.

[0009] In an embodiment of the present application, by triggering an operation in response to an update event of a code knowledge graph of a code library, a first Merkle tree corresponding to the code library after triggering is obtained, the first Merkle tree is compared with a second Merkle tree, and a changed file is determined, where the second Merkle tree is the Merkle tree corresponding to the code library before triggering, and each node value in the first Merkle tree and the second Merkle tree includes: a key composed of the path of the target entry corresponding to the node in the corresponding code library, and a value composed of the content hash value corresponding to the target entry. The code knowledge graph is updated according to the changed file. In this way, by comparing two Merkle trees, specific changed files can be identified and extracted, and the code knowledge graph is updated based on the changed file, realizing incremental update of the code knowledge graph, avoiding syntax parsing of code files during the comparison process, avoiding parsing unmodified code files multiple times, and not needing to locate the specific modified content, significantly improving the update efficiency of the code knowledge graph and ensuring the timeliness and consistency of the graph content.

[0010] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings herein are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0012] Figure 1 Shows a schematic flowchart of a method for updating a code knowledge graph provided by an exemplary embodiment of the present application; Figure 2 Shows a schematic diagram of a file directory provided by an exemplary embodiment of the present application; Figure 3 Shows a schematic structural diagram of a Merkle tree provided by an exemplary embodiment of the present application; Figure 4 Shows a schematic structural diagram of another Merkle tree provided by an exemplary embodiment of the present application; Figure 5Shows a schematic structural diagram of another Merkle tree provided by an exemplary embodiment of the present application; Figure 6a shows a schematic diagram of the relationship between entities in a Python code library provided by an exemplary embodiment of the present application; Figure 6b shows a schematic diagram of a code knowledge graph provided by an exemplary embodiment of the present application; Figure 7 Shows a schematic diagram of the hierarchical structure of a file directory provided by an exemplary embodiment of the present application; Figure 8 Shows a schematic structural diagram of a Merkle tree provided by an exemplary embodiment of the present application; Figure 9 Shows a schematic diagram of a multi-code knowledge graph system provided by an exemplary embodiment of the present application; Figure 10 Shows a schematic flowchart of a method for updating a code knowledge graph based on a multi-code knowledge graph system provided by an exemplary embodiment of the present application; Figure 11 Shows a schematic structural diagram of an electronic device provided by an exemplary embodiment of the present application. Detailed implementation manners

[0013] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0014] Figure 1 Shows a schematic flowchart of a method for updating a code knowledge graph provided by an exemplary embodiment of the present application. This method can be executed by an electronic device, and the electronic device can include: a terminal device and a network-side device. In other words, this method can be executed by software or hardware installed in the electronic device. The method can include the following steps: S110: In response to a trigger operation for an update event of the code knowledge graph of the code library, obtain the first Merkle tree corresponding to the code library after the trigger.

[0015] In an exemplary embodiment, the update event may include but is not limited to at least one of the following: (1) A timed task event, and the timed task event can be automatically triggered at a preset time interval.

[0016] (2) A version control event, and the version control event may include but is not limited to being triggered by the following events: triggered after local code submission.

[0017] (3) Trigger event, and other related events can be specified to trigger it.

[0018] (4) Manually trigger an event, that is, trigger it through a command line, an interface button, or an operation.

[0019] Among them, a Merkle tree is a binary tree or a multi-way tree, which consists of a root node, a set of intermediate nodes, and a set of leaf nodes. The bottommost leaf nodes contain the hash values corresponding to their node contents. Layer by layer upwards, each node is further hashed after concatenating the hash values of the contents of its child nodes. Finally, through layer-by-layer hash calculation, the root node of the Merkle tree is obtained.

[0020] S120: Compare the first Merkle tree with the second Merkle tree to determine the changed files.

[0021] Among them, the second Merkle tree is the Merkle tree corresponding to the code library before the trigger. Each node value in the first Merkle tree and the second Merkle tree includes: a key composed of the path of the target entry corresponding to the node in the corresponding code library, and a value composed of the content hash value corresponding to the target entry.

[0022] In the embodiments of the present application, whether the code library has changed can be detected by comparing Merkle trees. Among them, the first Merkle tree is constructed based on the current code library after the update event is triggered, and the second Merkle tree is constructed based on the code library after the previous update after the update event is triggered, or the second Merkle tree is constructed and saved when the previous update event is triggered. After this update event is triggered, the second Merkle tree can be directly obtained without reconstruction.

[0023] In the embodiments of the present application, each node value in the first Merkle tree and the second Merkle tree includes: a key composed of the path of the target entry corresponding to the node in the corresponding code library, and a value composed of the content hash value corresponding to the target entry. Among them, one node corresponds to one target entry, and the target entry includes a folder and the code files included in the folder. In the case where the target entry is a folder, the content hash value corresponding to the target entry is a secondary hash mapping based on the hash values of all the folders and code files included in the folder. In the case where the target entry is a code file, the content hash value corresponding to the target entry is the hash value of the corresponding content of the code file. Exemplarily, as Figure 2 shown, it is a schematic diagram of a code library directory provided by the embodiments of the present application, which includes a root directory: xxx code library. The xxx code library includes: folder 1 and code file 4. Folder 1 includes code file 1 and folder 2. Folder 2 includes code file 2 and code file 3. As Figure 3As shown, code file 1, code file 2, code file 3, and code file 4 are all leaf nodes, and their corresponding content hash values are determined based on the content they contain; the content hash value of folder 2 is obtained by performing a secondary hash mapping on the content hash values of code file 2 and code file 3; the content hash value of folder 1 is obtained by performing a secondary hash mapping on the content hash value of code file 1 and the content hash value of folder 2; the content hash value of the root directory "xxx code library" is obtained by performing a secondary hash mapping on the content hash value of code file 4 and the content hash value of folder 1. Among them, the key of each node is the path of the corresponding target entry in the corresponding code library, such as Figure 4 As shown, the key of the node corresponding to code file 2 is: xxx code library:\folder 1\folder 2\code file 2; the key of the node corresponding to code file 3 is: xxx code library:\folder 1\folder 2\code file 3; the key of the node corresponding to code file 1 is: xxx code library:\folder 1\code file 1; the key of the node corresponding to folder 2 is: xxx code library:\folder 1\folder 2; the key of the node corresponding to folder 1 is: xxx code library:\folder 1; the key of the node corresponding to code file 4 is: xxx code library:\code file 4; the key of the root node is: xxx code library:. Exemplarily, based on Figure 3 - Figure 4 , the Merkle tree corresponding to the directory hierarchy of this code library is as Figure 5 shown.

[0024] In an exemplary embodiment, the above S120 may include: in response to the root node value of the first Merkle tree being inconsistent with the root node value of the second Merkle tree, comparing the first Merkle tree with the second Merkle tree to determine the changed file.

[0025] It can be understood that each node in the first Merkle tree and the second Merkle tree is a secondary mapping of the combination of the hash values of its child nodes. The path from the leaf node to the root node constructs an immutable link for the data, so that any change in the data will cause a change in the root node. Therefore, by comparing the root node hash values of the two new and old Merkle trees, it can be quickly detected whether the root node of the tree has changed. If the root node hash values are different, it means that at least one leaf node, that is, the corresponding code file, has changed. It should be noted that only based on the change of the root node hash value, it can only be determined that the content in this code library has changed, but it cannot specifically determine which files have changed. Therefore, it is necessary to further compare the branch nodes layer by layer until the leaf nodes to identify the specific location of the difference, that is, to determine the changed file, so that the comparison process can be kept efficient when performing data consistency comparison.

[0026] S130: Update the code knowledge graph according to the changed file.

[0027] Among them, the code knowledge graph includes entities, relationships, and attributes.

[0028] Among them, the entity corresponds to a node in the graph, and the entity can include code elements such as classes, functions, variables, modules, declarations, etc. For example: User class, getUserInfo() function.

[0029] The relationship corresponds to an edge in the graph, and the relationship is used to describe the association between entities. The relationship can include but is not limited to the dependency relationship. Among them, the dependency relationship can include but is not limited to the call / called relationship, import / imported relationship, inherit from / base class relationship, define from / defined relationship, contain / belong to relationship, instantiate / being instantiated relationship, etc. Exemplarily, as Figure 6a shown, it is a schematic diagram of the relationship between entities in a Python code library.

[0030] The attribute is a characteristic of the entity or the relationship. For example: the location of the User class in the code library, attributes such as source code.

[0031] In the embodiment of the present application, the code knowledge graph can be constructed in the form of [entity, relationship, entity] triples. For example: [getUserInfo() function, instantiate, User class], [User class, being instantiated, getUserInfo() function], [getUserInfo() function, contain, userId variable], [userId variable, belong to, getUserInfo() function], [Module A, import, Module B], [Module B, being imported, Module A]. Exemplarily, as Figure 6b shown, it is a schematic diagram of a code knowledge graph. In an exemplary embodiment, the entity name of each entity is composed of the category of the entity and the hash value of its location in the code library. For example, module: 12345678, where module is the category of the entity, and 12345678 is the hash value of its location in the code library. In this embodiment, in order to keep the path of the entity confidential, its location in the code library can be mapped to a hash value.

[0032] In an exemplary embodiment, before S130, the method further includes: constructing a code knowledge graph corresponding to the code library. Among them, in another exemplary embodiment, the constructing a code knowledge graph corresponding to the code library may include: constructing an abstract syntax tree corresponding to the code library; constructing the code knowledge graph based on the abstract syntax tree.

[0033] Among them, in another exemplary embodiment, constructing the code knowledge graph corresponding to the code library may include: constructing the code knowledge graph using a graph constructor. Among them, constructing the code knowledge graph using a graph constructor may include: extracting code entities and dependencies in the source code using the graph constructor; passing the code entities and dependencies into a target class; constructing the code knowledge graph based on the target class. Among them, for the Python language, the graph constructor can be used to call the JEDI Python package to extract code entities in the source code, and the goto jump function of the JEDI package can be used to query the code entity definitions to construct cross-file dependencies. For other languages, a syntax parser generation tool that supports parsing any programming language can be used to extract code entities and dependencies in the source code, and this syntax parser generation tool can be the Tree-sitter Python package. The target class can be the MutiDiGraph class of the NetworkX Python package.

[0034] Further, in another exemplary embodiment, after constructing the code knowledge graph corresponding to the code library, the code knowledge graph can be exported as a file in a target format, and then the file in the target format can be imported into a cloud graph database, where the target format can be the JSON format. After importing the code knowledge graph into the cloud graph database, the code dependencies can be retrieved through various query methods, so as to support code completion plugins and code Q&A systems, thereby alleviating the hallucination problem of large models and improving the code completion adoption rate. Exemplarily, in the cloud database, the NebulaGraph Query Language (NQL) is used to retrieve entities whose names contain "x" in the code knowledge graph, and the retrieval results include the name, location attribute, and source code attribute of the entity: { "entity name": "module-5678", "attributes": { "source code": "function x()", "name": "x",...}. In the cloud database, the NQL statement is used to retrieve entities whose names contain "y" in the code knowledge graph, and the retrieval results include the name, location attribute, and source code attribute of the entity: { "entity name": "module-12345", "attributes": { "source code": "variable y = 1 ", "name": "y", "location": path: / xxx code library / folder 1 / y.py...}. In the cloud database, the NQL statement is used to retrieve all function entities called by entities whose names contain "main" in the code knowledge graph. As shown in Table 1, the retrieval results returned include the entity name, attributes, and the name and attributes of the function entities it calls.

[0035] Table 1

[0036] In the embodiments of the present application, the retrieval method may include retrieving information of entities and edges with specified attributes, retrieving information of nodes and edges that have dependency relationships with all entities in a specified code file, etc. It should be noted that the above retrieval examples are only for illustrative purposes, and the embodiments of the present application do not make specific limitations on the forms of expression and description of the retrieval method and retrieval results.

[0037] In an exemplary embodiment, after updating the code knowledge graph corresponding to the code library, the code knowledge graph can be exported as a file in a target format, and then the file in the target format can be imported into the cloud graph database, where the target format may be the JSON format. Exemplarily, in the cloud database, use the NQL statement to retrieve entities in the code knowledge graph whose names contain "x", and the retrieval results include the name, location attribute, and source code attribute of the entity. It should be noted that the retrieval results also include the newly added entity, that is, entity x is added to the updated code knowledge graph. Therefore, two "x" entities can be retrieved during the retrieval: {"entity name": "module-5678", "attributes": {"source code": "function x()", "name": "x",...}, {"entity name": "module-8910", "attributes": {"source code": "function x()", "name": "x",...}}. Use the NQL statement in the cloud database to retrieve entities in the code knowledge graph whose names contain "y", and the retrieval results include the name, location attribute, and source code attribute of the entity: {"entity name": "module-12345", "attributes": {"source code": "variable y = 1", "name": "y", "location": "path: / xxx code library / folder 1 / folder 2 / y.py,...". It should be noted that the location attribute of entity y in the updated code knowledge graph is different from the location attribute of entity y in the corresponding retrieval example of the constructed code knowledge graph. It should be noted that the above retrieval examples are only for illustrative purposes, and the embodiments of the present application do not make specific limitations on the forms of expression and description of the retrieval method and retrieval results.

[0038] In an exemplary embodiment, the newly added or modified entities in the updated code knowledge graph can be highlighted to provide a more intuitive graph change range for the user and help the user quickly understand the newly added or modified entities.

[0039] In the embodiments of the present application, one code knowledge graph corresponds to one code language. When the code library includes code files corresponding to multiple code languages, the code knowledge graphs corresponding to each code language in the code library can be constructed according to the code files corresponding to each code language. Among them, the code language may include, but is not limited to, Python, Java, Javascript, C / C++, Ruby, and Php. For the Python, Java, Javascript, C / C++, Ruby, and Php languages, their code files respectively refer to files with suffixes of.py,.java,.js,.c / .cpp,.rb, and.php.

[0040] In addition, the code knowledge graph in the embodiments of the present application can be applied to code completion and code Q&A.

[0041] In the embodiments of the present application, by responding to an operation triggered by an update event for the code knowledge graph of the code library, the first Merkle tree corresponding to the code library after triggering is obtained, and the first Merkle tree is compared with the second Merkle tree to determine the changed files. Among them, the second Merkle tree is the Merkle tree corresponding to the code library before triggering. Each node value in the first Merkle tree and the second Merkle tree includes: a key composed of the path of the target entry corresponding to the node in the corresponding code library, and a value composed of the content hash value corresponding to the target entry. The code knowledge graph is updated according to the changed files. In this way, by comparing the two Merkle trees, specific changed files can be identified and extracted, and the code knowledge graph is updated based on the changed files, realizing the incremental update of the code knowledge graph, avoiding the syntax parsing of code files during the comparison process, avoiding the repeated parsing of unchanged code files, and not needing to locate the specific modified content, significantly improving the update efficiency of the code knowledge graph and ensuring the timeliness and consistency of the graph content.

[0042] In an exemplary embodiment, obtaining the first Merkle tree corresponding to the code library after triggering may include the following steps: Step 1: Obtain the target entries in the file directory corresponding to the code library after the update event is triggered, where the position of the target entry in the file directory is identified by the corresponding path.

[0043] Step 2: Determine the key-value pair corresponding to each target entry, where the key-value pair is composed of the key and the content hash value, and the content hash value is determined based on the content included in the target entry or the content hash values of all the target entries subordinate to the target entry.

[0044] Step 3: According to the hierarchical relationship of the paths of each target entry, construct the first Merkle tree based on the key-value pair corresponding to each target entry.

[0045] Among them, the hierarchical relationship of the path can be associated through the parent-child relationship, that is, the parent-child relationship includes the association between a folder and its directly included sub-folders or code files. Exemplarily, as Figure 7 shown, for the Figure 2 hierarchical schematic diagram corresponding to the code library directory schematic diagram shown, which includes the first level, the second level, the third level, and the fourth level. The first level includes the xxx code library, the second level includes folder 1 and code file 4, the third level includes code file 1 and folder 2, and the fourth level includes code file 2 and code file 3. When constructing the first Merkle tree, it is constructed sequentially from bottom to top according to the hierarchical relationship. Exemplarily, as Figure 8 shown, the hierarchical relationship between the completed first Merkle tree and the directory hierarchical schematic diagram is consistent.

[0046] In addition, if there is no code file in a certain folder, a special "empty node" can be created, and its content hash value indicates that the folder is empty.

[0047] It should be noted that the construction method of the second Merkle tree is the same as that of the first Merkle tree, and will not be elaborated here.

[0048] In this embodiment, by constructing a Merkle tree to verify whether the code library has been modified, the consistency, integrity, and efficiency of data verification are ensured.

[0049] In an exemplary embodiment, comparing the first Merkle tree with the second Merkle tree to determine the changed files includes: comparing the keys of the first Merkle tree and the second Merkle tree to determine the deleted code files or newly added code files, where the changed files include the deleted code files or newly added code files.

[0050] It can be understood that the key of each node is composed of the path of the directory entry corresponding to the node. In the case of deleting a code file or adding a new code file in the current code library, it will involve changes in the directory structure. Therefore, it can be quickly known whether there are deleted code files or added code files only by comparing the keys.

[0051] In the embodiments of the present application, for deleted code files and newly added code files, starting from the root directory, recursively from top to bottom, it is determined whether the keys of the nodes at the same position in the same level of the two Merkle trees are the same. If they are exactly the same, it will be skipped and the recursion will not continue. If they are different, the recursion will continue until the deleted code file or newly added code file is obtained.

[0052] In another exemplary embodiment, determining the deleted code file or the newly added code file by comparing the keys of the first Merkle tree and the second Merkle tree may include the following steps: Step 1: Compare the keys corresponding to the nodes at the (n - 1)-th level of the first Merkle tree with the keys corresponding to the nodes at the (n - 1)-th level of the second Merkle tree, where the nodes for comparison between the first Merkle tree and the second Merkle tree are in the same position in the same level, n is an integer greater than 1, and n is the total number of levels; Step 2: In response to their consistency, recursively execute the above operation until they are inconsistent, to obtain the target nodes at the i-th level of the first Merkle tree and the second Merkle tree, where i is an integer greater than or equal to 1; Step 3: Determine the newly added code file according to the key of the target node at the i-th level of the first Merkle tree, or determine the deleted code file according to the key of the target node at the i-th level of the second Merkle tree.

[0053] It should be noted that if a certain code file is moved from path A under the file directory to path B, then the code file under path A can be determined as the deleted code file, and the code file under path B can be determined as the newly added code file.

[0054] Further, in an exemplary embodiment, the changed file includes the deleted code file, and the method further includes: deleting a first entity matching the deleted code file from the code knowledge graph to obtain a first changed code knowledge graph, where the changed file further includes the first changed code knowledge graph.

[0055] It can be understood that in the case where the changed file includes a deleted code file, it is necessary to delete the first entity matching the deleted code file from the code knowledge graph. Deleting the first entity does not affect the entities connected to the first entity by edges, because the relationships between the entities of other code files and the first entity do not need to be reconstructed. If there is a dependency relationship between other code files and the first entity, then after deleting the first entity, in order to ensure the correct operation of other code files, other code files need to be modified. Therefore, deleting the first entity does not affect the entities connected to the first entity by edges.

[0056] In the embodiments of the present application, the first entity can be found by filtering the entities in the graph whose location attribute contains "deleted code file". That is, the location attribute of the first entity contains the path of the deleted code file. Therefore, the corresponding first entity can be matched based on the path of the deleted code file.

[0057] In an embodiment of the present application, after deleting the first entity that matches the deleted code file from the code knowledge graph, a first changed code knowledge graph is obtained. This first changed code knowledge graph also needs to be used as a changed file to participate in the update of the final code knowledge graph. The introduction of the first changed code knowledge graph can achieve incremental update of the code knowledge graph, avoid repeated processing of the same data, and reduce computational overhead.

[0058] Further, in another exemplary embodiment, the changed file includes the newly added code file, and the method further includes: in response to the code library including a first associated code file, determining that the changed file further includes the first associated code file, where there is a dependency relationship between the code entities in the first associated code file and the code entities in the newly added code file.

[0059] It can be understood that after a code file is newly added to the code library, the code entities in the newly added code file may have a dependency relationship with the entities in other code files. Then the content of these code files must have been modified. Therefore, these code files, that is, the first associated code files, can be used as changed files to participate in the update of the code knowledge graph to ensure the accuracy and integrity of the code knowledge graph update.

[0060] In an exemplary embodiment, comparing the first Merkle tree and the second Merkle tree to determine the changed file includes: comparing the content hash values of the first Merkle tree and the second Merkle tree to determine the modified code file, where the changed file includes the modified code file.

[0061] It can be understood that when there is a modified code file in the current code library, there will be no change in the directory structure, and it is impossible to quickly know whether there is a modified code file by comparing the keys. Therefore, it is necessary to compare the hash values to determine whether there is a modified code file, that is, the modified code file.

[0062] In an embodiment of the present application, for a modified code file, starting from the root directory, it recursively traverses from top to bottom. If it is determined that the hash values corresponding to a path in the two Merkle trees are exactly the same, it will be skipped and will not continue to recurse on it. If they are different, it will continue to recurse until the modified code file, that is, the modified code file, is obtained.

[0063] In an exemplary embodiment, comparing the content hash values of the first Merkle tree and the second Merkle tree to determine the modified code file may include the following steps: Step 1: Compare the content hash values corresponding to the nodes at the (n - 1)-th level of the first Merkle tree and the content hash values corresponding to the nodes at the (n - 1)-th level of the second Merkle tree, where the keys of the nodes compared between the first Merkle tree and the second Merkle tree are the same, n is an integer greater than 1, and n is the total number of levels; Step 2: In response to their consistency, recursively execute the above operation until they are inconsistent, to obtain the target node at the i-th level of the first Merkle tree, where i is an integer greater than or equal to 1; Step 3: Determine the modified code file according to the content hash value of the target node at the i-th level of the first Merkle tree.

[0064] In an exemplary embodiment, comparing the content hash values of the first Merkle tree and the second Merkle tree to determine the modified code file may include the following steps: comparing the content hash values of the leaf nodes with the same key to determine the inconsistent leaf node pairs, where each leaf node pair includes a leaf node corresponding to the first Merkle tree and a leaf node corresponding to the second Merkle tree, and determining the modified code file according to the leaf node corresponding to the first Merkle tree.

[0065] Further, in another exemplary embodiment, after comparing the content hash values of the first Merkle tree and the second Merkle tree to determine the modified code file, the method further includes: deleting the second entity matching the modified code file from the code knowledge graph to obtain a second changed code knowledge graph, where the changed file further includes the second changed code knowledge graph.

[0066] It can be understood that for a modified code file, since its code node positions and source code attributes may change after modification, it is also necessary to delete all the nodes corresponding to its entities in the graph and reconstruct them. The second entity can be found by filtering the entities in the graph whose location attributes contain the "modified code file". In the embodiments of the present application, the second entity can be found by filtering the entities in the graph whose location attributes contain the "modified code file". That is to say, the location attribute of the second entity contains the path of the modified code file. Therefore, the corresponding second entity can be matched based on the path of the modified code file.

[0067] In this embodiment, using the second changed code knowledge graph as the changed file for updating the code knowledge graph can avoid repeated processing of the same data and reduce the computing overhead.

[0068] It should be noted that regarding the deletion of the second entity that matches the modified code file, it can be operated on the first changed code knowledge graph, that is, deleting the second entity that matches the modified code file from the first changed code knowledge graph, where the first changed code knowledge graph is obtained by deleting the first entity that matches the deleted code file from the code knowledge graph. Or, regarding the deletion of the first entity that matches the deleted code file, it can be operated on the second changed code knowledge graph, that is, deleting the first entity that matches the deleted code file from the second changed code knowledge graph, where the second changed code knowledge graph is obtained by deleting the second entity that matches the modified code file from the code knowledge graph. Or, for the deleted code file and the modified code file, the corresponding entities can be deleted from the code knowledge graph respectively to obtain the first changed code knowledge graph and the second changed code knowledge graph. Then, in the subsequent graph update process, the first changed code knowledge graph and the second changed code knowledge graph can be merged.

[0069] In an exemplary embodiment, after deleting the second entity that matches the modified code file from the code knowledge graph to obtain the second changed code knowledge graph, the method further includes: obtaining a third entity that has a dependency relationship with the second entity from the code knowledge graph; determining a second associated code file that includes the third entity according to the location attribute of the third entity, where the changed file further includes the second associated code file.

[0070] It can be understood that after deleting the second entity, some entities included in the code files are also affected, and the entity associations between the modified code files need to be reconstructed. Therefore, it is necessary to determine the code files affected, that is, the associated code files. When searching for the code files affected by the "second entity", the second entity can be traversed first, and then the code files where the entities with "called", "imported", "base class", "defined", "instantiated", etc., dependency relationships with the current second entity are located can be found. These code files are the code files affected by the "second entity", that is, the second associated code files.

[0071] In this embodiment, when the code library changes, first determine the directly modified code file, that is, the modified code file, and then trace layer by layer along the dependency relationship of the entity corresponding to the modified code file to identify all indirectly affected entities, and then determine the code file corresponding to the entity, that is, the associated code file. Then, use the second associated code file as the changed file to participate in the update of the code knowledge graph to ensure the accuracy and integrity of the code knowledge graph update.

[0072] In an exemplary embodiment, the above S130 may include: extracting code entities included in each code file in the change file and the corresponding dependency relationships of each code entity by using a graph update function; and updating the code knowledge graph based on the code entities and the dependency relationships. For the Python language, the code entities in the source code can be extracted by calling the JEDI Python package through a graph construction function, and the definition of the code entity can be queried through the goto jump function of the JEDI package to construct cross-file dependency relationships. For other languages, a syntax parser generation tool that supports parsing any programming language can be used to extract code entities and dependency relationships in the source code, and the syntax parser generation tool can be the Tree-sitter Python package. In another exemplary embodiment, the updating the code knowledge graph based on the code entities and the dependency relationships may include: passing the code entities and the dependency relationships into a target class; and updating the code knowledge graph based on the target class. The target class may be the MutiDiGraph class of the NetworkX Python package.

[0073] In yet another exemplary embodiment, the above S130 may include: constructing an abstract syntax tree corresponding to the code file in the change file; and updating the code knowledge graph based on the abstract syntax tree.

[0074] It should be noted that in the case where the change file only includes newly added code files or deleted code files, it is determined that the change file also includes the code knowledge graph. It can be understood that in the case where the change file only includes newly added code files or deleted code files, it is also necessary to input the constructed or last updated code knowledge graph so that the graph update function can perform an update based on this code knowledge graph. In another exemplary embodiment, if the change file also includes a first changed code knowledge graph or a second changed code knowledge graph, then there is no need to input the constructed or last updated code knowledge graph as the change file into the graph update function, and the graph update function can directly perform an update based on the first changed code knowledge graph or the second changed code knowledge graph.

[0075] In addition, the graph update function in this embodiment and Figure 1 the graph construction function in the illustrated embodiment may be the same or different.

[0076] Based on the foregoing embodiments, an embodiment of the present application further provides a multi-code knowledge graph system that supports addition, deletion, modification, and query, as Figure 9 shown. The multi-code knowledge graph system includes: A code knowledge graph construction module 910: configured to parse a code library and construct a repository-level code knowledge graph across files; Code knowledge graph import module 920: Used to import the generated graph file into the cloud graph database; Code library modification detection module 930: Used to detect modifications to the original code library, including modified, newly added, or deleted code files, and newly added or deleted folders; Code knowledge graph modification module 940: Used to synchronously feedback the changes detected by the code library modification detection module to the already constructed code knowledge graph; Code knowledge graph query module 950: Used to query information about nodes and edges based on the existing local code knowledge graph.

[0077] Among them, as Figure 10 shown, the processing flow of this multi-code knowledge graph system may include the following steps: S1010: Construct a code knowledge graph.

[0078] In this step, the code knowledge graph construction module 910 passes the code library address to the graph constructor, and the graph constructor will automatically construct the knowledge graph of the code library. Since the graph has the characteristics of high structuring and contains multiple (entity, relationship, entity) triples, it can be exported in JSON format and then passed into the graph database using the API. That is, after obtaining the JSON format output file, the code knowledge graph import module 920 can use the API to import it into the cloud graph database.

[0079] Among them, for the Python language, the graph constructor can use the JEDI Python package to extract code entities in the source code, including: classes, functions, variables, modules, declarations. And find the code entity definitions through the goto jump function of the JEDI package to build cross-file dependency relationships, which can include call / called relationships, import / imported relationships, inherit from / base class relationships, defined by / defines relationships, contain / belong to relationships, instantiate / be instantiated relationships, etc. For other languages, it uses the syntax parser generation tool Tree-sitter Python package that supports parsing any programming language to extract code module entities and extracts import / imported relationships through regular expressions. Finally, the extracted code entities and dependency relationships are passed into the MutiDiGraph class of the NetworkX Python package to construct the graph.

[0080] S1020: Obtain the first Merkle tree and the second Merkle tree corresponding to the code library.

[0081] In this step, when the code library modification detection module 930 detects that the code library has been modified, it can calculate the first Merkle tree corresponding to the current code library and the second Merkle tree corresponding to the code library before the modification.

[0082] Among them, the construction method of the Merkle tree is to calculate the hash value of the source code script or folder from bottom to top starting from the code script file. The hash value of the folder is the second hash mapping of the hash values of all the folders and source code scripts it contains. Using the path of the script or folder as the key and the hash value as the value, it is stored as a dictionary, which can be called the Merkle tree dictionary. The calculated Merkle tree dictionary and the code repository are stored in the database.

[0083] S1030: Determine whether the first Merkle tree and the second Merkle tree are consistent.

[0084] Among them, if they are inconsistent, go to S1040.

[0085] In this step, when the user re-uploads code to the code knowledge base, the code library modification detection module 930 will calculate the Merkle tree dictionary corresponding to the current code library and extract the previously saved Merkle tree dictionary. When it is found that the Merkle root in the previously saved Merkle tree dictionary is inconsistent, the Merkle tree dictionary is updated and the detection program is started.

[0086] S1040: Obtain the changed code files by comparing the first Merkle tree and the second Merkle tree.

[0087] Among them, the changed code files include at least one of the following: newly added code files, deleted code files, and modified code files.

[0088] In this step, by comparing the hash values of the nodes in the Merkle tree before and after, the paths of the added, deleted, and modified code files in the code library are obtained. First, by comparing the keys in the new and old Merkle tree dictionaries, the deleted or added folders and files are obtained. For the modified files, starting from the root directory, it recurses from top to bottom. When it is found that the hash value corresponding to a path in the Merkle tree dictionary is exactly the same, it skips and does not continue to recurse on it. If it is different, it continues to recurse until the modified code file is obtained. It should be noted that since only the code knowledge graph of the specified language needs to be constructed, this module only focuses on the modifications of the files corresponding to the specified code language, and ignores the changes of other types of files or folders that do not contain code files.

[0089] S: Update the code knowledge graph according to the changed code files.

[0090] In this step, the code knowledge graph modification module 940 can adopt different graph modification strategies for newly added code files, deleted code files, and modified code files. First, for deleted code files, all the code nodes contained in them can be directly deleted from the graph. These nodes are called "deleted nodes". It should be noted that each code node is an entity, and this will not be elaborated further. Deleting these "deleted nodes" will not affect the code nodes connected to these nodes by edges because the relationships between the nodes of other files and these "deleted nodes" do not need to be reconstructed. For modified code files, since their positions and source code attributes of the contained code nodes will change after modification, all the nodes in the graph also need to be deleted and reconstructed. These nodes are called "modified nodes". The "modified nodes" can be found by filtering the nodes in the graph whose position attributes contain "modified code file". However, after deleting these "modified nodes", it is necessary to reconstruct both the utilization of these "modified nodes" by other external nodes and the "utilization" of these nodes by external nodes. Therefore, it is necessary to determine which nodes in which files "utilize" these "modified nodes", that is, to find out Figure 2 the affected files. It should be noted that "utilization" here refers to the dependency relationship in the code relationship, such as "call", "import", "inherit from", "defined in", "instantiated", etc. When finding the files affected by the "deleted nodes", it is first necessary to traverse the modified nodes, and then find the files where the nodes with the utilization relationships such as "called by", "imported by", "base class", "defined", "instantiated by", etc. with the current node are located, that is, the files where the nodes that utilize the current node are located. These files are the files affected by the "deleted nodes" and can be called "affected code files". For newly added code files, there are two cases. Case 1: If the newly added code file is not "utilized" by other existing code files, then it does not affect other files. Case 2: If the newly added code file is "utilized" by other existing code files, then the other existing code files must have been modified. Therefore, these code files that "utilize" the newly added code file will be detected as "modified code files", and at this time, the logic for modifying the "modified code files" will be reused. Therefore, the "newly added code files" can be treated as "modified code files". Finally, the "modified code files", "newly added code files", "affected code files", and the graph after deleting the "deleted nodes" and "modified nodes" are input into the graph update function, and the update function will traverse the incoming files and use the abstract syntax tree tool to reconstruct the graph to complete the modification.

[0091] S1060: Import the code knowledge graph into the cloud graph database.

[0092] In this step, the code knowledge graph import module 920 can use the API to import it into the cloud graph database.

[0093] S1070: Perform graph query based on the code knowledge graph.

[0094] In the embodiments of the present application, for the locally generated graph, various query functions can be implemented through the support of MutilDiGraph in NetworkX for graphs, including but not limited to finding external nodes related to specified nodes, etc.; at the same time, after importing the code knowledge graph into the cloud graph database through the API, the same query functions as those on the local side can also be implemented.

[0095] Through the embodiments of the present application, users can extract the dependency relationship information of cross-file code entities in the code library as a knowledge graph, and can quickly identify the paths of the modified code files after adding, deleting, or modifying code files in the code library, and efficiently complete the modification of the corresponding knowledge graph. At the same time, it supports importing the graph into the cloud graph knowledge base for storage, and can retrieve code dependencies through various query methods as background knowledge to support code completion plugins and code Q&A systems, so as to alleviate the hallucination problem of large models and improve the code completion adoption rate.

[0096] As Figure 11 shown, the embodiments of the present application further provide an electronic device 1100, including a processor 1110 and a memory 1120. A program or instruction that can run on the processor 1110 is stored on the memory 1120. When the program or instruction is executed by the processor 1110, it implements the above Figures 1 to 10 shown embodiments of each process, and can achieve the same technical effects. To avoid repetition, it will not be elaborated here.

[0097] The embodiments of the present application further provide a computer-readable storage medium. A program or instruction is stored on the computer-readable storage medium. When the program or instruction is executed by a processor, it implements the above Figures 1 to 10 shown embodiments of each process, and can achieve the same technical effects. To avoid repetition, it will not be elaborated here.

[0098] Among them, the processor is the processor in the terminal described in the above embodiments. The computer-readable storage medium may include a computer read-only memory ROM, a random access memory RAM, a magnetic disk, or an optical disc, etc. In some examples, the computer-readable storage medium may be a non-transitory computer-readable storage medium.

[0099] The embodiments of the present application further provide a chip. The chip includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run a program or instruction to implement the above Figures 1 to 10 shown embodiments of each process, and can achieve the same technical effects. To avoid repetition, it will not be elaborated here.

[0100] It should be understood that the chip mentioned in the embodiments of the present application may also be referred to as a system-on-chip, system chip, chip system, or system-on-chip, etc.

[0101] The embodiments of the present application further provide a computer program / program product. The computer program product includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer is caused to execute the above-mentioned Figures 1 to 10 each process of the illustrated embodiment and can achieve the same technical effect. To avoid repetition, it will not be described in detail here.

[0102] It should be noted that in this article, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of another identical element in the process, method, article or device including that element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in a reverse order according to the functions involved. For example, the described methods may be performed in an order different from that described, and various steps may be added, omitted or combined. Additionally, the features described with reference to certain examples may be combined in other examples.

[0103] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of a computer software product plus a necessary general hardware platform, and of course, they can also be implemented by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.) and includes several instructions for causing a terminal or a network-side device to execute the methods described in various embodiments of the present application.

[0104] The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Under the inspiration of the present application, those of ordinary skill in the art can also make many forms of embodiments without departing from the purpose of the present application and the scope protected by the claims. These embodiments are all within the protection scope of the present application.

Claims

1. A method for updating a code knowledge graph, characterized in that, Including: In response to an update event of a code knowledge graph for a code repository, triggering an operation to obtain a first Merkle tree corresponding to the code repository after the trigger; Comparing the first Merkle tree with a second Merkle tree to determine changed files, where the second Merkle tree is the Merkle tree corresponding to the code repository before the trigger, and each node value in the first Merkle tree and the second Merkle tree includes: a key composed of the path of the target entry corresponding to the node in the corresponding code repository, and a value composed of the content hash value corresponding to the target entry; Updating the code knowledge graph according to the changed files.

2. The method according to claim 1, characterized in that, Obtaining the first Merkle tree corresponding to the code repository after the trigger includes: Obtaining the target entries in the file directory corresponding to the code repository after the update event is triggered, where the position of the target entry in the file directory is identified by the corresponding path; Determining the key-value pair corresponding to each target entry, where the key-value pair is composed of the key and the content hash value, and the content hash value is determined based on the content included in the target entry or the content hash values of all the target entries subordinate to the target entry; Constructing the first Merkle tree according to the key-value pairs corresponding to each target entry according to the hierarchical relationship of the paths of each target entry.

3. The method according to claim 1, characterized in that, The comparing the first Merkle tree with the second Merkle tree to determine changed files includes: Comparing the keys of the first Merkle tree and the second Merkle tree to determine deleted code files or newly added code files, where the changed files include the deleted code files or newly added code files.

4. The method according to claim 3, wherein When the changed files include the deleted code files, the method further includes: Deleting a first entity matching the deleted code file from the code knowledge graph to obtain a first changed code knowledge graph, where the changed files further include the first changed code knowledge graph.

5. The method according to claim 3, characterized in that, When the changed files include the newly added code files, the method further includes: In response to the code repository including a first associated code file, determining that the changed files further include the first associated code file, where there is a dependency relationship between the code entities in the first associated code file and the code entities in the newly added code file.

6. The method according to claim 1, wherein The comparing the first Merkle tree with the second Merkle tree to determine changed files includes: Comparing the content hash values of the first Merkle tree and the second Merkle tree to determine modified code files, where the changed files include the modified code files.

7. The method according to claim 6, characterized in that, After the comparing the content hash values of the first Merkle tree and the second Merkle tree to determine modified code files, the method further includes: Deleting a second entity matching the modified code file from the code knowledge graph to obtain a second changed code knowledge graph, where the changed files further include the second changed code knowledge graph.

8. The method according to claim 7, wherein After the deleting the second entity matching the modified code file from the code knowledge graph to obtain a second changed code knowledge graph, the method further includes: Obtain a third entity that has a dependency relationship with the second entity from the code knowledge graph; Determine a second associated code file that contains the third entity according to the location attribute of the third entity, wherein the change file further includes the second associated code file.

9. The method according to claim 1, characterized in that, The comparing the first Merkle tree and the second Merkle tree to determine the change file includes: In response to the root node value of the first Merkle tree being inconsistent with the root node value of the second Merkle tree, compare the first Merkle tree and the second Merkle tree to determine the change file.

10. The method according to claim 1, characterized in that The updating the code knowledge graph according to the change file includes: Use a graph update function to extract the code entities included in each code file in the change file and the corresponding dependency relationships of each code entity; Update the code knowledge graph based on the code entities and the dependency relationships.

11. An electronic device, characterized in that, It includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor. When the program or instruction is executed by the processor, it implements the steps of the method for updating the code knowledge graph according to any one of claims 1-10.

12. A computer-readable storage medium, characterized in that, A program or instruction is stored on the computer-readable storage medium. When the program or instruction is executed by a processor, it implements the steps of the method for updating the code knowledge graph according to any one of claims 1-10.

13. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer is caused to implement the steps of the method for updating the code knowledge graph according to any one of claims 1-10.

Images