Destructive change detection to a

Abstract

The invention relates to destructive change detection of a federated system. Systems and methods are provided for managing changes to a federated system. According to some aspects, changes to a federated system are received. A historical query is accessed from a query storage device that stores information related to queries received by the federated system. A query plan assessment is performed on the historical query based on a change to the federated system, and an action to be performed on the change is caused based on the query plan assessment.

Description

Technical Field

[0001] The present invention relates to destructive change detection for federated systems. Background Art

[0002] Federated systems (e.g., systems using GraphQL) provide a distributed architectural approach that enables efficient data management and integration across multiple data sources, referred to as subgraph services. In this model, each subgraph service maintains its own independent subgraph schema that describes the data it manages. The system combines the individual subgraph schemas into a single, cohesive, and interconnected supergraph schema. Consumers of a federated system can submit queries as a single endpoint to a gateway, which can employ the supergraph schema to generate a query plan to extract data from multiple subgraph services and return a response. The gateway can analyze each query and generate a query plan at runtime based on, for example, core library versions, combined versions, and subgraph schemas. Summary of the invention

[0003] Some aspects of the technology relate to managing changes to a federated system, among other things. These changes can be, for example, changes to a gateway of a federated system, changes to an existing subgraph service of a federated system, and / or the addition of a new subgraph service to a federated system. Aspects of the technology described herein detect when disruptive changes occur that will affect the performance of queries processed by the federated system, including changes that will prevent existing queries from being processed or that adversely affect query performance.

[0004] According to some aspects, information related to queries received by the federated system is persistently stored in a query storage device to facilitate evaluation of changes to the federated system. For example, queries received by the federated system can be stored as historical queries in the query storage device, and query plans generated for each query can be stored in association with each historical query as historical query plans. For each historical query, query metadata can also be persistently stored in the query storage device.

[0005] When a change to the federated system is received, a query plan evaluation is performed on at least a portion of the historical queries in the query storage device to determine whether and / or to what extent the change will affect the ability to continue processing queries corresponding to the historical queries. For a given historical query, the query plan evaluation includes determining whether a new query plan can be generated for the historical query in the event of the change. If a new query plan cannot be generated based on the change, the change can be prevented from being implemented and / or a notification related to the change and its impact can be sent to one or more related entities. When a new query plan can be generated, the performance impact of the new query plan is determined. An action related to the change is selected depending on the performance impact of the new query plan, such as allowing the change to be implemented (depending on the query plan evaluation of other historical queries), preventing the change from being implemented, and / or providing a notification related to the change and its impact to one or more related entities.

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Embodiments of the present technology are described in detail below with reference to the accompanying drawings, in which: Figure 1 is a block diagram illustrating an exemplary system according to some embodiments of the present disclosure; Figure 2 is a block diagram illustrating tracking and storing historical query information and storing it in a query storage device according to some embodiments of the present disclosure; Figure 3 is a block diagram illustrating verification of changes to a federated system according to some embodiments of the present disclosure; Figure 4 is a flow chart illustrating a method for tracking and storing data related to historical queries to a federated system according to some embodiments of the present disclosure; Figure 5 is a flow chart illustrating a method for verifying changes to a subgraph service and / or gateway of a federated system according to some embodiments of the present disclosure; Figure 6 is a flow chart illustrating a method for performing query plan evaluation on historical queries in the event of one or more changes to a subgraph service and / or gateway of a federated system according to some embodiments of the present disclosure; and Figure 7 is a block diagram of an exemplary computing environment suitable for use in embodiments of the present disclosure. DETAILED DESCRIPTION

[0008] Overview While federated systems provide a powerful tool for building distributed, scalable APIs, updates to federated systems present multiple problems. Specifically, maintenance of a federated system typically involves changes to the gateway (such as gateway library or code version updates) and changes to backend subgraph services (such as adding new subgraph services, removing existing subgraph services, modifying existing subgraph services, and adding / removing / modifying subgraph instructions). Each of these updates has the potential to be a destructive change that affects the ability to process existing queries. In some cases, the changes may cause some existing queries to degrade in performance (e.g., increased computer resource consumption, increased latency); while in other cases, the changes cause the federated system to no longer be able to fully process some existing queries. For example, if a change to a subgraph scheme for one subgraph service destroys the interdependency with the subgraph scheme of another subgraph service, the change may cause the federated system to be unable to run existing queries that rely on the interdependency.

[0009] There have been some limited attempts to address the issues brought on by changes to federated systems. For example, one solution tracks field usage in subgraph schemas and provides reports when there is an attempt to rename or delete a field that is in use. However, this solution only provides notification of field changes and does not address whether and to what extent these changes will affect existing queries. Additionally, this solution does not address potential issues introduced by gateway changes. As a result, changes to federated systems remain difficult to manage.

[0010] Aspects of the technology described herein improve the functionality of the computer itself by providing a system that determines whether changes to a federated system (e.g., changes to a gateway and / or subgraph service) will break queries - that is, cause the query to no longer run and / or affect query performance. This determination can be performed at build time before the changes are implemented into the federated system at runtime. If the updates are destructive changes that affect the ability to execute a particular query, implementation of the changes can be prevented.

[0011] According to some aspects of the technology described herein, queries received from client devices and processed by the federated system are persistently stored as historical queries in a query storage device. Query plans used to run these queries are also persistently stored as historical query plans in a query storage device. In some cases, query metadata about historical queries (e.g., issuing applications, associated APIs, frequency of use of the query, recency of use of the query, query type, query owner, etc.) are also persistently stored in the query storage device.

[0012] When a change to a gateway or subgraph service is received, an evaluation is performed at build time (e.g., before implementing the change in the federated system) to determine whether the change will disrupt historical queries. For each historical query, determine whether a new query plan can be generated based on the change. If not, the change can be blocked and a notification provided to the development team, administrator of the federated system, and / or query owner that implemented the change. If a new query plan can be generated for a given historical query, the new query plan is compared with the historical query plan for the historical query, and an action is performed based on the comparison. For example, if the new query plan matches the historical query plan or the new query plan will not affect performance, the change can be allowed (at least for the historical query). Alternatively, if the new query plan does not match the historical query plan and / or the new query plan will affect query performance, the change can be blocked and a notification provided to the development team, administrator of the federated system, and / or query owner that implemented the change.

[0013] Aspects of the technology described herein provide multiple improvements over existing federated system management methods. For example, aspects of the present technology allow determining whether and to what extent an update to a federated system is a destructive change that affects the ability of the federated system to process existing queries. Query plan evaluations performed according to aspects of the technology described herein allow evaluations to be performed on any type of changes to a federated system. According to some aspects, the system not only determines that the change will affect query performance, but also determines to what extent the query performance will be affected. In addition, notifications provided to related entities can provide information related to destructive changes and associated query metadata that allows guidance to analyze whether to implement the change regardless of its impact. For example, if the query is a query that is no longer needed, a query that is a test query, or a query that is not frequently used, a decision to implement the change can be made. In some cases, the information provided in the notification can facilitate the development team to modify these changes and / or facilitate query owners to modify existing queries. In this way, resources are saved in the management of a federated system.

[0014] Example federated system with destructive change detection Now referring to the accompanying drawings, Figure 11 is a block diagram showing an exemplary system 100 according to some embodiments of the present disclosure. It should be understood that this and other arrangements described herein are set forth as examples only. In addition to or in place of the arrangements and elements shown, other arrangements and elements (e.g., machines, interfaces, functions, sequences, groupings of functions, etc.) may be used, and some elements may be omitted entirely. In addition, many of the elements described herein are functional entities that may be implemented as discrete or distributed components or in combination with other components, and implemented in any suitable combination and position. The various functions performed by one or more entities described herein may be performed by hardware, firmware, and / or software. For example, the various functions may be performed by a processor that executes instructions stored in a memory.

[0015] System 100 is an example of a suitable architecture for implementing some aspects of the present disclosure. System 100 includes, among other components not shown, a query source device 102 and a federation system 104 . Figure 1 Each of the components of the illustrated federation system 104 and the query source device 102 may include one or more computer devices, such as those discussed below. Figure 7 The computing device 700. Figure 1 As shown, the query source device 102 and the joint system 104 can communicate via a network 106, which may include, but is not limited to, one or more local area networks (LANs) and / or wide area networks (WANs). Such network environments are common in offices, enterprise-wide computer networks, intranets, and the Internet. It should be understood that within the scope of the present technology, any number of devices can be used within the system 100. Each device may include a single device or multiple devices collaborating in a distributed environment. For example, the joint system 104 can be provided by multiple devices that jointly provide the functions of the joint system 104 as described herein. In addition, other components not shown may also be included in the network environment.

[0016] Federation system 104 provides an architecture for building distributed, scalable APIs. At a high level, federation system 104 processes queries from query source devices, such as query source device 102, and returns responses to the query source devices. Query source device 102 may include any device that initiates a query to federation system 104. For example, query source device 102 may be a user device or other device with a web application, mobile application, or other application that acts as a consumer of an API provided via federation system 104. Although for simplicity, Figure 1 Only a single query source device 102 is shown in FIG. 1 , but it should be understood that the federation system 104 can service queries from any number of query source devices.

[0017] like Figure 1As shown, the federation system 104 includes a gateway 108 that coordinates and optimizes queries from query source devices (such as query source device 102) across multiple subgraph services 110A to 110N. The subgraph services 110A to 110N include backend services that encapsulate different data and / or functions for servicing queries from the query source devices. For example, the federation system 104 may have subgraph services for user data, product data, promotional data, etc. Although for simplicity, Figure 1 Only three sub-graph services 110A, 110B, 110N are shown, but it should be understood that the federation system 104 may include any number of sub-graph services.

[0018] Each of the subgraph services 110A to 110N exposes its own subgraph schema, which defines the data stored by the subgraph service and how to query the data. The subgraph schemas from the various subgraph services 110A to 110N are combined into a hypergraph schema that is stored in the schema registry 114. The hypergraph schema provides a unified schema used by the gateway 108 to orchestrate queries across the subgraph services 110A to 110N.

[0019] The gateway 108 acts as an intermediary between a query source device (such as the query source device 102) and the subgraph services 110A to 110N. When the gateway 108 receives a query from a query source device, the gateway 108 uses a hypergraph solution from the solution registry 114 to process the query. For example, the gateway 108 may use the hypergraph solution to understand how to process the query across related subgraph services. In some cases, this may include: generating a query plan based on the hypergraph solution, and executing the query plan across one or more subgraph services 110A to 110N. The query plan may specify which subgraph services need to be queried and how the results should be combined. After generating the query plan, the gateway 108 may send subqueries to the appropriate subgraph services. Each subgraph service processes its subqueries and returns results that are combined into a response, which is provided, for example, to the query source device that submitted the query.

[0020] According to some aspects of the techniques described herein, the federation system 104 tracks and records information about queries in the query storage 112. For example, the federation system 104 can store the query received and processed by the gateway 108 as a historical query in the query storage 112. The federation system 104 can also store the query plan generated for the query as a historical query plan in the query storage 112. The federation system can also store query metadata for the query in the query storage 112. The query metadata for the query can include various information useful when validating changes to the federation system 104. By way of example only and not limitation, the query metadata can include information identifying the application that originated the query, the API, the query owner (e.g., the entity responsible for maintaining the application or API), the entity that submitted the query (e.g., an end user or a developer), the type of query (e.g., a test query submitted by a developer or a query submitted by an application), the frequency of use of the query (e.g., the number of times the query has been received and processed by the federation system 104 over a period of time), and the recency of use of the query (e.g., a timestamp when the query was last received and processed by the federation system).

[0021] Figure 2 2 is a block diagram illustrating a process 200 for tracking historical query information and storing it in a query storage device. Figure 2 As shown, at gateway 204 (which may correspond to Figure 1 The query 202 is received at a gateway 108 of the query source device (such as Figure 1 The query source device 102 of the embodiment of the present invention may submit a query 202, for example, via an API call. Based on the query 202, the gateway 204 may store various query information in a query storage device 208 (which may correspond to Figure 1 The query storage device 112).

[0022] In some configurations, the gateway 204 processes the query 202 based on whether the gateway 204 has previously processed other queries that match the current query 202. For example, the gateway 204 may initially perform a query check on the query store 208 to determine whether a query matching the query 202 has been previously processed by the gateway or otherwise stored in the query store 208 as a historical query with an associated historical query plan.

[0023] In the event that query 202 does not match historical queries in query storage 208, gateway 204 retrieves a query from solution registry 206 (which may correspond to Figure 1The hypergraph schema is accessed by the gateway 204 (schema registry 114) and the hypergraph schema is used to generate a query plan for the query 202. The query 202 is stored in the query storage device 208 as a historical query, and the query plan generated by the gateway 204 is stored in the query storage device 208 as a historical query in association with the historical query. Query metadata may also be stored in the query storage device 208 in association with the historical query. The query metadata may include, for example, information identifying the application that initiated the query, the API, the query owner, the entity that submitted the query, the type of query, the number of times the query has been received (initializing the count in the case of the first time the query is seen), and a timestamp associated with the time when the gateway 204 received / processed the query.

[0024] In some cases where query 202 matches a historical query with an associated historical query plan in query storage 208, gateway 204 may use the historical query plan to process query 202 instead of generating a new query plan. In this case, gateway 204 may update query metadata stored in query storage 208 in association with the historical query based on the instance of query 202. As described above, query metadata may include, for example, information identifying the application that initiated the query, the API, the query owner, the entity that submitted the query, the type of query, an update to the number of times the query has been received, and a timestamp associated with the time when gateway 204 received / processed the query. In other cases where query 202 matches a historical query in query storage 208, gateway 204 generates a query plan using a hypergraph scheme to process query 202 instead of using the associated historical query plan from query storage 208. For example, changes to the federated system since the query was last processed may dictate the generation of a new query plan. In this case, the new query plan is stored in query storage 208 as a historical query plan, and the query metadata is updated.

[0025] Reference again Figure 1 , federated system 104 also includes a validation component 116. Validation component 116 evaluates changes to federated system 104 (eg, before implementing the changes) to determine whether and / or to what extent the changes will affect the ability of federated system 104 to process queries from query source devices (such as query source device 102).

[0026] Figure 3 is a block diagram illustrating a process 300 for verifying changes to a federated system. Figure 3 As shown, in the verification component 304 (which may correspond to Figure 1One or more changes 302 to the federated system are received at a verification component 116 of the federated system. Changes 302 may be submitted to verification component 304, for example, via a pipeline used by a development team to maintain the federated system. Changes 302 may include, among other things, changes to a gateway (e.g., Figure 1 gateway 108) and / or to one or more subgraph services (e.g., Figure 1 For example, changes to the gateway may include a gateway library update or a gateway code upgrade (e.g., logic used by the gateway to generate a query plan for a query). Changes to subgraph services may include, for example, adding new subgraph services (and their associated subgraph schemes), removing existing subgraph services, or modifying existing subgraph services (e.g., adding / removing fields in a subgraph scheme, changing field dependencies within a subgraph scheme or between subgraph schemes, etc.), and adding / removing / modifying subgraph instructions.

[0027] Verification component 304 evaluates change 302 to determine whether and / or to what extent change 302 will affect the processing of the query by the federated system. Specifically, verification component 304 performs verification on the query stored in query storage device 306 (which may correspond to Figure 1 112). For a given historical query, the verification component 304 accesses the historical query and its associated historical query plan from the query storage device 306. The verification component 304 attempts to generate a new query plan for the historical query based on the change 302. For example, if a change to a subgraph solution is received, the verification component 304 generates a new hypergraph solution based on the changed subgraph solution and attempts to generate a new query plan using the new hypergraph solution. As another example, if a gateway code upgrade is received, the verification component retrieves a query plan from the solution registry 308 (which may correspond to Figure 1 The solution registry 114) accesses the existing hypergraph solution and attempts to generate a new query plan using the existing hypergraph solution and the new gateway code.

[0028] In some cases, the change 302 prevents the verification component 304 from being able to generate a new query plan. In this case, the verification component 304 can cause the change 302 to be prevented from being implemented in the federated system and / or cause one or more notifications 310 to be sent to related entities.

[0029] In other cases, the verification component 304 can generate a new query plan for the historical query based on the change. In this case, the verification component 304 compares the new query plan with the historical query plan associated with the historical query. If the new query plan matches the historical query plan, the implementation of the change 302 will not affect the processing of the historical query. Alternatively, if the new query plan does not match the historical query plan, the verification component 304 evaluates the performance impact of the new query plan and selects an action based on the performance impact.

[0030] In some configurations, the validation component 304 evaluates the performance impact of the new query plan based on a comparison of the query performance of the new query plan with the query performance of historical query plans. In other configurations, the validation component 304 evaluates the performance impact of the new query plan based on the query performance of the new query plan without considering the query performance of historical query plans. The query performance of a query plan can be determined, for example, based on the computational cost of running the query plan (e.g., in terms of resource consumption such as processor usage, memory usage, bandwidth consumption, and I / O requirements) and / or the length of time required to process the query plan.

[0031] The validation component 304 selects an action based on the performance impact of the new query plan. In some aspects, the validation component 304 compares the performance impact of the new query plan to one or more thresholds. For example, where a single threshold is used, if the performance impact of the new query is below the threshold, then the performance impact is determined to be acceptable so that the change 302 can be implemented for the historical query. Alternatively, if the performance impact of the new query exceeds the threshold, the validation component 304 can cause the change 302 to be blocked from being implemented in the federated system and / or cause one or more notifications 310 to be sent to relevant entities.

[0032] When a new query plan cannot be generated based on the change 302 and / or the new query plan has an adverse effect on query performance, a notification 310 is sent to the relevant entity, which can be transmitted electronically over a network to the developer / development team that submitted the change 302, the administrator of the federated system, and / or the device of the query owner associated with the query. The notification 310 may, for example, include information identifying the historical query and information indicating that the change 302 will prevent the federated system from being able to process the historical query and / or the change will affect query performance. The notification 310 may also include query metadata associated with the historical query from the query storage device 306. The notification 310 provides information that allows the relevant entity to determine whether to implement the change 302 in the federated system regardless of the impact on the ability to process the query. For example, the query owner may determine that the performance impact is acceptable, so the change can be implemented. As another example, the query owner may decide to update the application so that the query is no longer used or a different query is used. In some configurations, the notification 310 provides one or more user interface elements that allow the receiving entity to determine whether to approve or deny the implementation of the change 310 in the federated system. Notification 310 may also provide information about the breaking changes that facilitate resolution of the issue, such information helping the development team to modify the changes and / or helping the query owner to update the application that submitted the query.

[0033] The process of evaluating the effect of the change 302 on query processing by the validation component 304 can be performed on any number of historical queries in the query storage device 306. In some configurations, the query plan evaluation is performed on all historical queries in the query storage device 306, while in other configurations, the query plan evaluation is performed on a subset of the historical queries in the query storage device 306. For example, the query plan evaluation can be performed on a sampling (e.g., a random sampling) of historical query plans. In some configurations, whether to perform a query plan evaluation on a given historical query can be based on query metadata associated with the historical query. For example, if the query metadata associated with the historical query indicates that the historical query is a test query, the historical query has not been used within a threshold time period, or the frequency of use of the historical query does not meet a threshold, the system can determine not to perform a query plan evaluation on the historical query.

[0034] If the verification component 304 determines that the change 302 does not affect any of the historical queries being evaluated and / or the relevant entity approves the change 302 regardless of the impact on one or more historical queries, the verification component 304 causes the change to be implemented in the federated system. In the case of a gateway change, the gateway is updated. In the case of a subgraph service change, the updated supergraph solution is stored in the solution registry 308.

[0035] Example method for destructive change detection in a federated system Reference now Figure 4 , provides a flowchart illustrating a method 400 for tracking and storing data related to historical queries of a federated system. The method 400 may be performed by, for example Figure 1 Each block of method 400 and any other method described herein includes a computing process performed using any combination of hardware, firmware, and / or software. For example, various functions can be performed by a processor executing instructions stored in a memory. The method can also be embodied as computer usable instructions stored on a computer storage medium. These methods can be provided by a stand-alone application, a service or a hosted service (standalone or in combination with another hosted service), or a plug-in to another product, to name a few.

[0036] As shown in block 402, a query is received at a gateway of a federated system from a source device. At block 404, a determination is made as to whether the query has been previously received and processed by the federated system. For example, a query storage device (e.g., Figure 1 The query storage device 112 of the query storage device is used to determine whether the query received at block 402 matches a historical query in the query storage device.

[0037] If the query received at block 402 is determined to match a historical query, query metadata for the historical query is updated in the query storage device, as shown in block 406. For example, the query metadata may include a timestamp when the query was received, an update of the number of times the query has been received, and additional information about the query. In some cases, the gateway generates a new query plan that is different from the historical query plan associated with the historical query in the query storage device. In this case, the new query plan is also stored in the query storage device.

[0038] As shown in box 408, if the query received at box 402 is determined not to match the historical query, a new query plan is generated for the query. At box 410, the query, query plan, and query metadata are stored in a query storage device. Specifically, the query is stored as a historical query, and the query plan is stored as a historical query plan corresponding to the historical query. The query metadata stored for the historical query may include, for example, a timestamp when the query was received, an initialization of the number of times the query has been received, the type of query, the query owner, the application that issued the query, and / or an associated API.

[0039] Next turn Figure 5 , a flow chart illustrating a method 500 for verifying changes to a subgraph service and / or gateway of a federated system is provided. The method 500 may be performed by, for example Figure 1 In some aspects, method 500 is performed at build time when changes to the federated system are submitted before the development team implements the changes in the federated system.

[0040] As shown in Figure 502, one or more changes to the federated system are received. Changes can be submitted by a developer / development team attempting to update the federated system. Changes can include, for example, adding new subgraph services (and their associated subgraph schemes), removing existing subgraph services, modifying existing subgraph services (e.g., adding / removing fields in subgraph schemes, changing field dependencies within or between subgraph schemes, etc.), adding / removing / modifying subgraph instructions, gateway library updates, and gateway code upgrades (e.g., the logic used by the gateway to generate query plans for queries).

[0041] From query storage devices (for example, Figure 1 The query storage device 112 of the federation system accesses historical queries and corresponding historical query plans, as shown in block 504. The historical query is a query from a source device that has been received by the federation system and stored in the query storage device. The corresponding historical query plan is a query plan generated by the gateway and stored in the query storage device. In some cases, query metadata for the historical query is also accessed from the query storage device. In some aspects, the query metadata is used to select whether to evaluate the historical query.

[0042] As shown in block 506, query plan evaluation is performed on the historical query based on the one or more changes received at block 502. Query plan evaluation may include performing the following reference Figure 6 Method 600 described. In general, query plan evaluation may include evaluating whether a new query plan can be generated for a historical query, and if a new query plan is generated, evaluating whether and / or to what extent the new query plan will affect performance. For example, in the case where the change received at block 502 is a change to a subgraph scheme, a new hypergraph scheme is generated based on the subgraph scheme, and the new hypergraph scheme is used to attempt to generate a new query plan. In the case of a change to a gateway of a federated system (such as a library update or a code upgrade), a new query plan is generated using the updated library or code upgrade.

[0043] At block 508, an action is taken based on the query plan evaluation performed at block 506. Various actions that can be taken based on the query plan evaluation include: preventing implementation of the changes received at block 502; allowing implementation of the changes received at block 502 (depending on the evaluation of other historical queries); providing notification to the developer / development team that submitted the changes; providing notification to an administrator of the federated system; and providing notification to a query owner associated with the historical query. When a notification is generated, the notification may identify various information, such as an indication of the historical query, an indication of the change, whether a new query plan can be generated, whether the new query plan affects performance (and / or the degree to which performance is affected), aspects that affect whether a new query can be generated and / or affect query performance, and / or query metadata for the historical query retrieved from the query storage device. In some aspects, the notification may provide one or more user interface elements that allow the developer / administrator / query owner to select whether to allow or prevent implementation of the change in the federated system.

[0044] although Figure 5 The process for a single historical query is shown, but method 500 can be performed for any number of historical queries from a query storage device. In some cases, historical queries are selected for evaluation based on query metadata associated with each historical query. For example, one or more rules that indicate whether to evaluate a historical query based on its associated query metadata can be employed. As an example to be illustrated, a rule can be established so that certain types of queries (e.g., test queries) are not evaluated, so that any historical query with query metadata indicating that the historical query is one of these query types will not be evaluated.

[0045] Figure 6 A flow chart is provided showing a method 600 for performing query plan evaluation on historical queries in the event of one or more changes to a subgraph service and / or gateway of a federated system. For example, at block 506 within the context of method 500, method 600 may be performed. Method 600 may be performed by, for example Figure 1 The verification component 116 is executed.

[0046] As shown at block 602, in the event of one or more changes to the federated system (e.g., the changes received at block 502 of method 500), an attempt is performed to generate a new query plan for a historical query (e.g., the historical query accessed from the query store at block 504 of method 500). A determination is made at block 604 as to whether a new query plan can be generated for the historical query in the event of the changes to the federated system.

[0047] If a new query plan cannot be generated, an action is selected based on the determination, as shown in block 606. For example, the selected action may include preventing the change from being implemented in the federated system, and / or creating a notification that a new query plan cannot be generated and providing the notification to the developer / development team that submitted the change, an administrator of the federated system, and / or a query owner of the historical query.

[0048] Alternatively, if a new query plan can be generated, as shown in block 608, the new query plan is compared to a historical query plan associated with the historical query (e.g., the historical query plan accessed from the query storage device at block 504 of method 500). A determination is made at block 610 as to whether the new query plan matches the historical query plan.

[0049] If the new query plan matches the historical query plan, then an action is selected that allows the change to be implemented on the federated system (subject to query plan evaluation of other historical queries), as shown in block 612. Alternatively, if the new query plan does not match the historical query plan, then the performance impact of the new query plan is evaluated, as shown in block 614.

[0050] An action is selected based on the performance impact assessment, as shown in block 616. For example, if the performance impact is below a threshold, an action may be selected to implement the change to the federated system. Alternatively, if the performance impact is above a threshold, an action may be selected to block the change to the federated system. In addition to blocking or allowing the change to be implemented, the selected action may also include creating a notification about the new query plan that is provided to the developer / development team that submitted the change, an administrator of the federated system, and / or a query owner of the historical query that is being evaluated.

[0051] Similar to the comments above for method 500, although Figure 6 The query plan evaluation process is shown for a single historical query, but method 600 may be performed for any number of historical queries from a query store. In some cases, historical queries are selected for evaluation based on query metadata associated with each historical query.

[0052] Exemplary Operating Environment Having described the embodiments of the present disclosure, an exemplary operating environment in which embodiments of the present technology can be implemented is described below to provide a general context for various aspects of the present disclosure. Figure 7 , an exemplary operating environment for implementing embodiments of the present technology is shown and generally designated as computing device 700. Computing device 700 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the technology. Neither should computing device 700 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

[0053] The present technology may be described in the general context of computer code or machine-usable instructions, which include computer-executable instructions (such as program modules) executed by a computer or other machine (such as a personal data assistant or other handheld device). In general, program modules, including routines, programs, objects, components, data structures, etc., refer to code that performs specific tasks or implements specific abstract data types. The present technology can be practiced in a variety of system configurations including handheld devices, consumer electronics, general-purpose computers, more specialized computing devices, etc. The present technology may also be practiced in distributed computing environments, where tasks are performed by remote processing devices linked through a communications network.

[0054] refer to Figure 7 , computing device 700 includes bus 710 that directly or indirectly couples the following devices: memory 712, one or more processors 714, one or more presentation components 716, input / output (I / O) ports 718, input / output components 720, and an illustrative power supply 722. Bus 710 represents what may be one or more buses (such as an address bus, a data bus, or a combination thereof). Although for clarity, Figure 7 The various boxes of FIG. 1 are represented by lines, but in reality, it is not so clear to depict the various components, and metaphorically, the lines would more accurately be gray and fuzzy. For example, a presentation component such as a display device can be considered an I / O component. In addition, a processor has memory. The inventors recognize that this is the nature of the art and reiterate that Figure 7 The figures are merely illustrative of exemplary computing devices that can be used in conjunction with one or more embodiments of the present technology. No distinction is made between categories such as "workstation," "server," "laptop," "handheld device," etc., as all of these categories are in the same Figure 7 and refers to “computing devices”.

[0055] The computing device 700 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computing device 700, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media.

[0056] Computer storage media includes volatile and nonvolatile, and removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by the computing device 700. Computer storage media themselves do not include signals.

[0057] Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in the form of a modulated data signal (such as a carrier wave or other transmission mechanism), and includes any information transmission medium. The term "modulated data signal" refers to a signal that is set or changed in a manner that encodes the information in the signal, and the signal has one or more characteristics. By way of example and not limitation, communication media include wired media such as a wired network or a direct wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0058] Memory 712 includes computer storage media in the form of volatile and / or non-volatile memory. Memory may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. Computing device 700 includes one or more processors that read data from various entities such as memory 712 or I / O components 720. Presentation component 716 presents data indications to a user or other device. Exemplary presentation components include display devices, speakers, printing components, vibration components, etc.

[0059] I / O port 718 allows computing device 700 to be logically coupled to other devices including I / O component 720, some of which may be built-in. Illustrative components include microphones, joysticks, game controllers, satellite antennas, scanners, printers, wireless devices, etc. I / O component 720 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological inputs generated by a user. In some cases, the input may be sent to an appropriate network element for further processing. NUI may implement any combination of the following: voice recognition, touch and stylus recognition, facial recognition, biometric recognition, gesture recognition on and near the screen, air gestures, head and eye tracking, and touch recognition associated with a display on computing device 700. Computing device 700 may be equipped with a depth camera (such as a stereo camera system, an infrared camera system, an RGB camera system, and a combination thereof) for gesture detection and recognition. In addition, computing device 700 may be equipped with an accelerometer or gyroscope capable of detecting motion.

[0060] The present technology has been described with reference to specific embodiments which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the present technology pertains without departing from the scope of the present technology.

[0061] Various components used herein have been identified, and it should be understood that any number of components and arrangements can be used to implement the desired functions within the scope of the present disclosure. For example, for conceptual clarity, the components in the embodiments depicted in the accompanying drawings are shown with lines. Other arrangements of these and other components can also be implemented. For example, although some components are depicted as single components, many elements described herein can be implemented as discrete or distributed components or combined with other components, and implemented in any suitable combination and position. Some elements can be omitted completely. In addition, the various functions performed by one or more entities described herein can be performed by hardware, firmware and / or software as described below. For example, various functions can be performed by a processor that executes instructions stored in a memory. Therefore, in addition to or in place of the arrangements and elements shown, other arrangements and elements (e.g., machines, interfaces, functions, commands, and functional groupings) can also be used.

[0062] The embodiments described herein may be combined with one or more of the specifically described alternatives. Specifically, the claimed embodiments may include references to more than one other embodiment in the alternatives. The claimed embodiments may specify additional limitations of the claimed subject matter.

[0063] The subject matter of embodiments of the present technology is specifically described herein to meet statutory requirements. However, this description itself is not intended to limit the scope of this patent. On the contrary, the inventors have contemplated that the claimed subject matter may also be embodied in other ways in combination with other prior art or future technologies to include different steps or combinations of steps similar to the steps described in this document. In addition, although the terms "step" and / or "box" may be used herein to refer to different elements of the method employed, these terms should not be interpreted as implying any particular order between or among the various steps disclosed herein, unless the order of the various steps is explicitly described.

[0064] For purposes of this disclosure, the word "including" has the same broad meaning as the word "comprising," and the word "accessing" includes "receiving," "referencing," or "retrieving." Furthermore, the word "communicating" has the same broad meaning as the word "receiving" or "sending," which is facilitated by a software or hardware-based bus, receiver, or transmitter using the communication media described herein. In addition, unless otherwise indicated, words such as "a," "an," and "an" include the plural as well as the singular. Thus, for example, where there are one or more features, the constraint of "a feature" is satisfied. In addition, the term "or" includes conjunctions, disjunctions, and both (a or b therefore includes a or b, and a and b).

[0065] For the purpose of the above detailed discussion, embodiments of the present technology are described with reference to a distributed computing environment; however, the distributed computing environment described herein is exemplary only. Components may be configured to perform novel embodiments in the embodiments, where the term "configured to" may refer to "programmed to" perform a specific task or implement a specific abstract data type using code. In addition, while embodiments of the present technology may generally refer to the technical solution environments and schematic diagrams described herein, it should be understood that the described technology may be extended to other implementation contexts.

[0066] From the foregoing it will be seen that the technology is well adapted to attain all of the ends and purposes set forth above, and other advantages which are obvious and inherent to the system and method. It will be appreciated that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations. This is contemplated by the claims and is within the scope of the claims.

Claims

1. One or more computer storage media storing computer usable instructions that, when used by a computing device, cause the computing device to perform operations comprising: receiving changes to federated systems; accessing a first historical query from a query storage device, the query storage device storing a plurality of historical queries received by the federation system; performing a query plan evaluation on the first historical query based on the changes to the federated system; as well as Based on the query plan evaluation, an action is caused to be performed on the change.

2. One or more computer storage media according to claim 1, wherein: The changes to the federated system include changes to a gateway of the federated system, changes to an existing subgraph service of the federated system, or addition of a new subgraph service to the federated system.

3. The one or more computer storage media of claim 1, wherein: The operations also include: storing the plurality of historical queries in the query storage device; storing a corresponding historical query plan in association with each historical query of the plurality of historical queries; and Corresponding query metadata is stored in association with each of the multiple historical queries, wherein the corresponding query metadata for the first historical query includes information indicating one or more items selected from the following items: an application that initiated the first historical query, an API associated with the first historical query, a frequency of use of the first historical query, a recency of use of the first historical query, a query type of the first historical query, and a query owner associated with the first historical query.

4. The one or more computer storage media of claim 1, wherein: The operations also include: evaluating query metadata associated with a first historical query in the query store; and A determination is made based on the evaluation to perform the query plan evaluation on the first historical query.

5. The one or more computer storage media of claim 1, wherein: Performing the query plan evaluation on the first historical query based on the change to the federated system includes: determining that a new query plan cannot be generated for the first historical query based on the change to the federated system; and Wherein causing an action to be performed based on the query plan evaluation comprises one or more selected from: preventing changes to the federated system, providing a first notification to a developer attempting to make changes to the federated system, and providing a second notification to a query owner of the first historical query.

6. The one or more computer storage media of claim 1, wherein: Performing the query plan evaluation on the first historical query based on the change to the federated system includes: generating a new query plan for the first historical query based on the changes to the federated system, performing a comparison of the new query plan with a first historical query plan associated with the first historical query, and Based on the comparison, determining that the new query plan matches the first historical query plan; and Wherein causing an action to be performed based on the query plan evaluation includes: allowing implementation of a change to the federated system based on a determination that the new query plan matches the first historical query plan.

7. The one or more computer storage media of claim 1, wherein: Performing the query plan evaluation on the first historical query based on the change to the federated system includes: generating a new query plan for the first historical query based on the changes to the federated system, performing a comparison of the new query plan with a first historical query plan associated with the first historical query, Based on the comparison, determining that the new query plan is different from the first historical query plan; and determining a performance impact associated with the new query plan; and Wherein causing an action to be performed based on the query plan evaluation includes: selecting the action based on a performance impact associated with the new query plan.

8. The one or more computer storage media of claim 7, wherein: Actions caused to be performed based on the query plan evaluation include: When the performance impact satisfies a threshold, performing one or more selected from: blocking changes to the federated system, providing a first notification to a developer attempting to make changes to the federated system, and providing a second notification to a query owner of the first historical query; and When the performance impact does not satisfy the threshold, implementation of the change to the federated system is permitted.

9. The one or more computer storage media of claim 1, wherein: Causing an action to be performed based on the query plan evaluation includes one or more selected from: providing a first notification to a developer attempting to make a change to the federated system, and providing a second notification to a query owner of the first historical query; as well as The first notification and / or the second notification includes information related to query metadata for the first historical query, and the query metadata for the first historical query includes one or more items selected from the following items: an application that initiates the first historical query, an API associated with the first historical query, a frequency of use of the first historical query, a recency of use of the first historical query, a query type of the first historical query, and a query owner associated with the first historical query.

10. A computer-implemented method comprising: Receive changes to a gateway or subgraph service of a federated system; accessing from a query storage device a plurality of historical queries previously received by the federated system; performing a query plan evaluation on each of the plurality of historical queries based on the change to the gateway or subgraph service of the federated system; as well as Based on an evaluation of query plans of the plurality of historical queries, an action is caused to be performed on the modification.

11. The computer-implemented method of claim 10, wherein: The method further comprises: storing the plurality of historical queries in the query storage device; storing a corresponding historical query plan in association with each historical query of the plurality of historical queries; Corresponding query metadata is stored in association with each of the multiple historical queries, wherein the corresponding query metadata for each historical query includes information indicating one or more items selected from the following items: an application that initiated the historical query, an API associated with the historical query, a frequency of use of the historical query, a recency of use of the historical query, a query type of the historical query, and a query owner associated with the historical query.

12. The computer-implemented method of claim 10, wherein: The method further comprises: evaluating query metadata associated with each of the plurality of historical queries; and A determination is made based on the evaluation to perform the query plan evaluation on each of the plurality of historical queries.

13. The computer-implemented method of claim 10, wherein: Performing the query plan evaluation on a first historical query of the plurality of historical queries includes: determining that a new query plan cannot be generated for the first historical query based on the change to the federated system; and Wherein causing the action to be performed based on the query plan evaluation comprises one or more selected from the following: blocking the change, providing a first notification to a developer attempting to make the change, and providing a second notification to a query owner of the first historical query.

14. The computer-implemented method of claim 10, wherein: Performing the query plan evaluation on a first historical query among the plurality of historical queries includes: Based on the change, generating a new query plan for the first historical query, performing a comparison of the new query plan with a first historical query plan associated with the first historical query, and Based on the comparison, determining that the new query plan matches the first historical query plan; and Wherein causing an action to be performed based on the query plan evaluation includes: allowing implementation of a change to the federated system based on a determination that the new query plan matches the first historical query plan.

15. The computer-implemented method of claim 10, wherein: Performing the query plan evaluation on a first historical query among the plurality of historical queries includes: generating a new query plan for the first historical query based on the changes to the federated system; performing a comparison of the new query plan with a first historical query plan associated with the first historical query, Based on the comparison, determining that the new query plan is different from the first historical query plan; and determining a performance impact associated with the new query plan; and Wherein causing an action to be performed based on the query plan evaluation includes: selecting the action based on a performance impact associated with the new query plan.

16. The computer-implemented method of claim 15, wherein: Actions caused to be performed based on the query plan evaluation include: When the performance impact satisfies a threshold, performing one or more selected from: blocking changes to the federated system, providing a first notification to a developer attempting to make changes to the federated system, and providing a second notification to a query owner of the first historical query; and When the performance impact does not satisfy the threshold, implementation of the change to the federated system is permitted.

17. A computer system comprising: one or more processors; as well as One or more computer storage media storing computer usable instructions that, when used by one or more processors, cause the one or more processors to perform operations comprising: receiving changes to federated systems; accessing a first historical query from a query storage device, the query storage device storing a plurality of historical queries received by the federation system; performing a query plan evaluation on the first historical query based on the changes to the federated system; and The modification is determined to be blocked based on the query plan evaluation.

18. The computer system of claim 17, wherein: Executing the query plan evaluation on the first historical query includes: It is determined that a new query plan cannot be generated based on the changes to the federated system.

19. The computer system of claim 17, wherein: Executing the query plan evaluation on the first historical query includes: generating a new query plan based on the changes to the federated system; and A performance impact of the new query plan is determined.

20. The computer system of claim 19, wherein: The performance impact of the new query plan is determined based on determining that the new query plan does not match a first historical query plan associated with a first historical query in the query store.

Images