Recursive Data Traversal Model

Abstract

To provide a method for performing a data cache of objects.SOLUTION: A recursive data traversal model interprets a configuration graph to efficiently and optimally construct requests and fetches data from a data store. The values of objects of a requested data type are used to generate additional queries for pre-fetching data from the data store. Specifically, the values are used to query for and retrieve a corresponding subset of objects of another, related data type. Recursively querying for and retrieving objects of related data types based on already retrieved objects builds a data cache of relevant objects. The cached, relevant objects may be useful in subsequent queries that are likely to follow the initial query.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] Technical Field The present disclosure relates to a recursive data traversal model, and more particularly, to a recursive data traversal model that implements data retrieval relationships. [Background technology]

[0002] background The client device may receive updates from the backend server or may submit updates to the backend server. The updates received or submitted by the client device may include updates to data. Summary of the Invention [Problem to be solved by the invention]

[0003] The client device may operate in an online mode and an offline mode. The online mode is a mode in which the client device can communicate with the backend server over a network. The offline mode is a mode in which the client device cannot communicate with the backend server over a network. When operating in the online mode, the client device can receive updates from the backend server and submit updates to the backend server. When operating in the offline mode, the client device cannot receive updates from or submit updates to the backend server.

[0004] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Thus, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[0005] Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. It should be noted that references to "an" or "one" embodiment in this disclosure do not necessarily refer to the same embodiment, but rather mean at least one. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a block diagram illustrating a client-server computing system operating on a network in accordance with one or more embodiments. [Figure 2] FIG. 1 is a block diagram illustrating components of a data control model according to one or more embodiments. [Figure 3] 1 is a block diagram illustrating an example set of operations for updating an object type definition in accordance with one or more embodiments. [Figure 4] 1 is a block diagram illustrating an example set of operations for updating an object type definition in accordance with one or more embodiments. [Figure 5] FIG. 2 is a block diagram illustrating a configuration graph showing relationships between entities and related entities, according to one or more embodiments. [Figure 6] FIG. 2 is a block diagram illustrating components of an entity in a configuration graph according to one or more embodiments. [Figure 7] FIG. 2 is a block diagram illustrating components of related entities in a configuration graph in accordance with one or more embodiments. [Figure 8] 1 is a block diagram illustrating an example set of operations for updating a data cache in accordance with one or more embodiments. [Figure 9] FIG. 1 is a block diagram illustrating a computer system according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0007] Detailed Description In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in another embodiment. In some instances, well-known structures and devices are described with reference to block diagram form in order to avoid unnecessarily obscuring the present invention.

[0008] 1.Overview One or more embodiments translate the configuration graph to efficiently and optimally construct requests and fetch data from the data store. Values ​​of objects of the requested data type are used to generate additional queries to prefetch data from the data store. Specifically, these values ​​are used to query for and retrieve a corresponding subset of objects of another related data type. A data cache of related objects is built by recursively querying for and retrieving objects of the related data type based on already retrieved objects. The cached related objects may be useful in subsequent queries that may be made after the initial query.

[0009] Certain embodiments other than those described in this general summary section may be included herein and may be set forth in the accompanying claims.

[0010] 2. Architecture Overview 1 shows a block diagram illustrating a client-server computing system 100 operating on a network 120 according to one or more embodiments. The client-server computing system 100 may include a server 110 and a client device 130 communicatively coupled via the network 120. The server 110 and the client device 130 may each include a computing processor and associated memory and communication circuitry.

[0011] The network 120 may be a local area network (LAN), a wide area network (WAN), an Ethernet (registered trademark), ) networks, token ring networks, asynchronous transfer mode (ATM) networks, Wi-Fi networks, the Internet, cellular networks, Enhanced Data rates for GSM Evolution (EDGE) networks, Long Term Evolution (LTE) networks, The network 120 may include a long-term evolution (LTE) network, a Worldwide Interoperability for Microwave Access (WiMAX) network, or other computing communication network. The server 110 may include a data store 115 that stores data accessible by the client device 130 over the network 120. The client device 130 may include a client application 135 (e.g., a software application) that receives data from or accesses data stored in the data store 115.

[0012] In one embodiment, client device 130 is implemented on one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device may also refer to a physical device or virtual machine that runs an application. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, special-function hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address translators (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile handsets, smartphones, personal digital assistants (PDAs), and the like. These include PDAs, wireless receivers and / or transmitters, base stations, communication managers, routers, switches, controllers, access points, and client devices.

[0013] In one or more embodiments, data store 115 is any type of storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, or any other storage mechanism). Furthermore, data store 115 may include multiple different storage units and / or devices. The multiple different storage units and / or devices may or may not be of the same type, or may or may not be located at the same physical site. Alternatively, or additionally, data store 115 may be implemented or run on a computing system separate from server 110. Data store 115 may be communicatively coupled to server 110 or client device 130 by a direct connection or via network 120.

[0014] Client applications 135 may access data objects stored in data store 115 using a set of hypertext transfer protocol (HTTP) uniform resource identifiers (URIs), such as uniform resource locators (URLs) used with HTTP requests. HTTP may be used as a request-response protocol between client device 130 and server 110 to facilitate the transfer and management of data between client applications 135 and data store 115.

[0015] The server 110 may provide a representational state transfer (REST) ​​service for servicing REST requests received from the client application 135. REST requests are implemented using stateless HTTP REST requests are a type of request that may be sent by client device 130 to server 110. REST requests are a subset of HTTP requests. REST requests may use a predefined, uniform set of stateless operations. When REST requests are used, state may not be maintained for each request. Server 110 may provide a description of server 110 as a REST server to client application 135 through a well-defined URL. Through this well-defined URL, server 110 may provide a mechanism for client application 135 to efficiently retrieve data from and upload data to data store 115.

[0016] In one or more embodiments, a user interface refers to hardware and / or software configured to facilitate communication between a user and a client device 130. A user interface renders user interface elements and receives input through user interface elements. Examples of interfaces include graphics, Examples of user interface elements include check boxes, radio buttons, drop-down lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms.

[0017] In one embodiment, various components of the user interface are specified in various languages. The behavior of the user interface elements is specified in a dynamic programming language such as JavaScript. The content of the user interface elements is specified in hypertext markup language (HTML) or XML. Markup languages ​​such as XML User Interface Language (XUL) The layout of user interface elements is specified in a style sheet language such as Cascading Style Sheets (CSS). Alternatively, the user interface is specified in one or more other languages ​​such as Java, C, or C++.

[0018] In one or more embodiments, client-server computing system 100 may include more or fewer components than those shown in FIG. 1. The components shown in FIG. 1 may be local or remote with respect to one another. The components shown in FIG. 1 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into a single application and / or machine. Operations described with respect to one component may instead be performed by another component.

[0019] Further embodiments and / or examples relating to computer networks are described below in Section 5 entitled "Computer Networks and Cloud Networks."

[0020] 3. Adaptive Polymorphic Data Model FIG. 2 shows a block diagram illustrating components of a data control model 200 according to one or more embodiments. The data control model 200 may be an embodiment of an adaptive polymorphic data model. The data control model 200 may describe a database schema used by a client application 135. The server 110 may provide elements of the data control model 200 from the data store 115 to the client application 135. The functionality and / or features of the client application 135 may be controlled as a function of the data control model 200. Thus, the client application 135 may provide different functionality when equipped with different elements of the data control model 200. Updates to the data control model 200 may be used to update the functionality of the client application 135 without updating the executable code of the client application 135. Thus, new functionality may be added to an existing client application 135 by sending new elements of the data control model 200 from the server 110 to the existing client application 135.

[0021] In one example, a single client application 135 may be made available to any customer of the software provider via a central application download portal on a network. Each customer of the software provider may desire different functionality for their respective client application 135 than other customers. Rather than providing different executable client applications 135 to each different customer, the software provider may provide the same executable client application 135 to all customers. The software provider may provide a different data control model 200 for each customer to be downloaded from each customer's respective server 110 to each customer's respective client application 135.

[0022] For example, Company A may have a dedicated instance of server 110 that is accessible only to Company A's employees via a set of client devices 130 issued by Company A to Company A's employees. All client devices 130 used by Company A's employees may download client applications 135 from a publicly available application portal. Additionally, Company B may have a dedicated instance of server 110 that is accessible only to Company B's employees. Company B's employees may access server 110 via a set of client devices 130 issued by Company B to Company B's employees. All client devices 130 used by Company B's employees may download client applications 135 from the same publicly available application portal as Company A's employees. Company A's instance of server 110 may download a data control model 200 customized for Company A to the client applications 135 on Company A's client devices 130. Company B's instance of server 110 may download a data control model 200 customized for Company B to the client applications 135 on Company B's client devices 130. As a result, even if the executable client application 135 downloaded from a publicly available application portal is the same for all client devices 130 of Company A and all client devices 130 of Company B, the client application 135 for Company A's employees may provide different functionality than the client application 135 for Company B's employees.

[0023] The data control model 200 may include one or more object type definitions 230. Each object type definition 230 may define an object type. The object type definition 230 may specify the attributes of the object type. Example attributes may include sales order, delivery date, quantity, revenue, etc. The object type definition 230 may also specify the data format of the attribute, e.g., text string, length of text string, character, integer, signed integer, unsigned integer, floating point, double precision floating point, character or integer array, array dimension, etc. The object type definition 230 may also specify a default value for each attribute of the object type. The object type definition 230 may also specify which fields are required to be included in each view of the defined object type and which fields are required to be included in all standard views of the defined object type. For example, delivery date may be a required field for a sales order data object type. The object type definition 230 may also specify which fields can be modified by the client application 135 and which fields do not need to be modified. For example, revenue may be a field for a sales order data object type that client application 135 cannot modify. Object type definition 230 may also specify functions that client application 135 should use to communicate with server 110 for the object type. Examples of such functions may include fetch, update, delete, etc. The functions specified in object type definition 230 include information to be used by client application 135 to construct URLs for communicating with server 110 for objects defined by the respective object type definition 230. Such communication may include sending values ​​of the object's data fields to data store 115 and updating the values ​​of the object's data fields in data store 115. A URL for updating the values ​​of the object's data fields in data store 115 may be specified.

[0024] The data control model 200 may also include one or more metadata modules 235. The metadata modules 235 may be embodied as data files or data objects. Each metadata module 235 may identify fields for an object type defined by a respective object type definition 230. For example, multiple different metadata modules 235 may identify different sets of fields for the same object type defined by a respective object type definition 230. Different metadata modules 235 corresponding to the same object may each define a different view or shape of the object type. The server 110 may store a complete or full standard representation of an object type in the data store 115. Client applications 135 may download various subsets of the full set of fields for an object type stored in the data store 115 to coordinate and function according to the metadata modules 235. Downloading partial objects from the data store 115 may result in savings in communication bandwidth over the network 120 and memory usage on the client device 130. The alternative of downloading a full standard representation of an object type every time an object type is operated on, regardless of which portion of the object type is to be operated on, may be inefficient.

[0025] As an example, a client application 135 may use a metadata module 235 representing a small subset of fields of a data object type to download a list of data objects from the data store 115. The client application 135 may use an HTTP request sent from the client device 130 to the server 110 to access a list of data objects in the data store 115 having field values ​​for a given field that match search parameters specified by the client application 135. The client application 135 may specify an object subtype defined in the metadata module 235 so that a desired subset of fields of a data object is downloaded, rather than the complete or full canonical representation of the data object. Thus, the subtype defined in the metadata module 235 facilitates the client application 135 downloading partial objects rather than the entire standard object from the data store 115.

[0026] For example, a data object type may be sales orders. The client application 135 may download a list of sales orders for a specified customer, or a specified seller, or a specified time period, etc. The client application 135 may present the list of sales orders in a user interface. A user may select one or more of the presented list of sales orders to view more data about the sales orders or to perform operations on the sales orders. In response to a user selection, the client application 135 may download additional details about the selected one or more of the presented list of sales orders using another metadata module 235 that represents a larger subset of the fields of the sales order data object type. A sales order data object type defined in each object type definition 230 may have several different associated metadata modules 235. Each metadata module 235 may represent a different level of detail for the sales order data object type. The level of detail may range from a minimal list view to a full standard view that includes all of the data fields of the sales order data object type.

[0027] In addition to specifying the various views of the objects defined in the object type definition 230, the metadata module 235 also specifies how the objects behave, interact with each other, and display in the user interface of the client application 135. The metadata module 235 may also specify whether to interact with the device and whether to interact with the server 110. The metadata module 235 may specify the layout of an object and multiple offsets associated with each field of an object.

[0028] The data control model 200 may include one or more polymorphism entities 205. Each polymorphism entity 205 may define different overall functionality for the data control model 200. When operating according to one polymorphism entity 205, the client application 135 may provide different features or functionality than when the client application 135 operates according to another polymorphism entity 205.

[0029] Each polymorphic entity 205 may include one or more persistent entities 210. The persistent entities 210 of one instance of a polymorphic entity 205 may differ from the persistent entities 210 of another instance of a polymorphic entity 205. Each instance of a persistent entity 210 may represent an instance of a data object as defined in a corresponding object type definition 230.

[0030] A persistent entity 210 may be an abstract representation of a data object. The persistent entity 210 may include a unique identifier 215 that uniquely identifies each instance of the persistent entity 210 within a particular polymorphic entity 205. The persistent entity 210 may also include an object type definition 220 that defines the object type represented by the persistent entity 210. The object type definition 220 may be an embodiment of a corresponding object type definition 230. The persistent entity 210 may also include a plurality of data values ​​225. Each of the plurality of data values ​​225 may be associated with a data field name defined in the object type definition 220.

[0031] Persistent entity 210 may include functionality defined by object type definition 220, which operates on data values ​​225 and interacts with data store 115 by referencing data object types as defined by object type definition 220. Executable code included in client application 135 that implements persistent entity 210 may not have built-in information about the data objects represented by object type definition 220. Executable code included in client application 135 may provide functionality according to the data included in object type definition 220. In one embodiment, persistent entity 210 may be implemented by Java code within client application 135, and object type definition 220 may be specified according to a JavaScript Object Notation (JSON) representation provided by data store 115. In various embodiments, other programming languages ​​and database formats may be used to implement persistent entities 210 in client application 135. Java code for persistent entities 210 may be provided to client application 135 at design time, and a JSON representation of object type definition 220 may be provided via data store 115 at run time.

[0032] For example, an instance of persistent entity 210 may be an object that is an instance of a sales order data type that is defined according to a class that includes methods for operating on the sales order data type. The class may be defined by object type definition 230. According to the class definition, persistent entity 210 may be able to construct HTTP requests as appropriate to operate with sales order data objects stored in data store 115, including fetching sales order data objects, updating sales order data objects, etc. The functionality provided by persistent entity 210 that operates on data objects stored in data store 115 may include: In general, persistent entities 210 may be defined to operate on any type of data object stored in data store 115. The functionality provided by persistent entities 210 may be invoked by methods provided in the classes in which persistent entities 210 are defined according to object type definitions 220. Executable code in client application 135 may be defined to operate only on "Revenue" objects, for example. Defined GetRevenue( <object identifier>) instead of a hard-coded function named , Get(), which is a hard-coded function called Get(Revenue, <object identifier>) on a field named "Revenue." In this case, <object identifier>is a part of the corresponding persistent entity 210. The unique identifier 215.

[0033] In one example, when client application 135 fetches a list of sales order data objects from data store 115, each returned sales order object may be represented by a separately defined instance of persistent entity 210. The sales order data objects returned in the list may be represented as subtypes of all standard sales order data types stored in data store 115 according to the metadata module 235 corresponding to the list of sales order data object types. A user may select one of the sales order data objects in the list to request the associated "Revenue" field value. The "Revenue" field may not be included in the subtype of the sales order data type according to the metadata module 235 corresponding to the list. Get(Revenue, <identifier>) function returns the persistent entity corresponding to the selected sales order data object. The Get function may be executed by the persistent entity 210. The Get function may look up the “Revenue” field in the persistent entity's object type definition 220 to determine what kind of data the “Revenue” field contains and look up the value for the field in the data value 225. If the value is not included in the data value 225, the Get function may issue an HTTP request to the data store 115 according to the metadata module 235 that includes the field “Revenue” for the sales order data object type. After receiving the “Revenue” data field and any other data fields defined by the metadata module 235 used by the Get function, the Get function may perform processing on the “Revenue” data value according to the class definition of the method corresponding to the Get function, as specified by the object type definition 220. The persistent entity 210 may then present the “Revenue” data value returned by the Get function to the user via the user interface of the client application 135.

[0034] Each customer of a software provider may desire different functionality from other customers for their respective client application 135. Rather than providing different executable client applications 135 to each different customer, the software provider may provide all customers with the same executable client application 135. The software provider may also provide each customer with a different data control model 200 to be downloaded from each customer's respective server 110 to each customer's respective client application 135.

[0035] In some embodiments, a particular customer of a software provider that provides a client application 135 to a particular customer may desire to update the functionality of the client application 135 used by or under the control of the particular customer. The updated functionality may include new data object type definitions 230 (e.g., for warehouse data objects in a new region), new metadata modules 235, updates to either or both of the existing data object type definitions 230 and metadata modules 235, etc. The particular customer may wish to update the software tool. A particular customer may update the data control model 200 on the server 110 of the particular customer using the executable client application 135. The particular customer may send the updated data control model 200 to one or more of the particular customer's instances of the particular customer's client application 135 on various client devices 130 under the particular customer's control. A particular customer's updates of the particular customer's client application 135 on various client devices 130 under the particular customer's control may not affect instances of the client application 135 provided by the software provider to other customers of the software provider. All of the software provider's customers may install and use the same executable client application 135. A particular customer may update the data control model 200 used by the particular customer's instance of the client application 135 without affecting any other instances of the client application 135.

[0036] In one embodiment, a seller may use client application 135 to display a list of sales opportunities, each of which is represented by an object type "Opportunities" in data control model 200 of client application 135. In response to a request from a seller, the client application 135 may display a list of values ​​for data fields from “opportunity” objects that meet the seller's criteria. The client application 135 may determine, based on the configuration of the client application 135, that only the customer name and customer phone number are displayed in the list view of opportunities. The client application 135 may analyze the metadata module 235 corresponding to the object type “opportunity.” The client application 135 may determine that the metadata module 235 corresponding to the object type “opportunity” includes the fields to be displayed, customer name and customer phone number. The client application 135 may retrieve values ​​for the fields identified in the corresponding metadata module 235 from the data store 115. Because the fields to be displayed are included in the corresponding metadata module 235, the client application 135 may retrieve values ​​for the customer name and customer phone number from objects of type “opportunity” stored in the data store 115. The client application 135 may display the retrieved information for each of the various opportunities in the list view.

[0037] In addition to storing values ​​for customer name and customer number, data store 115 may store a value for the field customer budget in the object type "opportunity." However, because customer budget is not identified in the corresponding metadata module 235 used by client application 135, client application 135 may not obtain a copy of the value corresponding to customer budget.

[0038] In one embodiment, client application 135 may receive a user request for a value of a field of an object that is not included in the corresponding metadata module 235. Client application 135 may search metadata module 235 for another corresponding metadata module 235 that contains the requested field for the specified object type. Client application 135 may then download the object from data store 115 according to the other corresponding metadata module 235 that contains the requested field. Client application 135 may modify a locally stored partial copy of the object previously retrieved from the server to include fields and values ​​obtained from data store 115 that correspond to the other corresponding metadata module 235 that contains the requested field for the specified object type.

[0039] Continuing with the example above, the client application 135 While the application 135 is displaying opportunities in a list view, it may receive a selection of a particular opportunity from a seller. The client application 135 may be configured to present a detailed view of an opportunity in response to receiving the selection. The client application 135 may determine that the detailed view of the opportunity includes a customer name, a customer phone number, and a customer budget. Based on an analysis of the corresponding metadata module 235, the client application 135 may determine that the corresponding metadata module 235 identifies fields for the customer name and the customer phone number. The client application 135 may further determine that the corresponding metadata module 235 does not identify a field customer budget. Because the corresponding metadata module 235 does not identify a field customer budget, it may be determined that any version of the object corresponding to the particular opportunity stored by the client application according to the corresponding metadata module 235 does not include a value for the field customer budget. The client application 135 may identify another metadata module 235 in the data control model 200 that corresponds to the object type “opportunity” that includes the desired field customer budget. The client application 135 may then request, from the data store 115 on the server 110, values ​​corresponding to the fields identified in another metadata module 235, including the field customer budget. Specifically, the client application 135 may request an object of type "opportunity" corresponding to the particular opportunity selected by the seller. In response to submitting the request, the client application 135 may receive an object of type "opportunity" corresponding to the particular opportunity selected by the seller. The object may now include values ​​for the customer name, customer number, and customer budget, all of which are identified in the other metadata module 235 maintained by the currently selected client application 135 to define its view of the particular object.Alternatively, the object received from data store 115 may not include values ​​for customer name and customer number if those values ​​have not changed since the last time they were received by client application 135. Client application 135 may replace or overwrite any previous version of the object stored that corresponds to a particular opportunity. Client application 135 may store a new version of the object that includes the customer name, customer phone number, and customer budget and that corresponds to a particular opportunity. Client application 135 may display a detailed view of a particular opportunity selected by the seller. The detailed view displayed by client application 135 may include the customer name, customer number, and customer budget.

[0040] In one embodiment, an application on server 110 may receive a request to create a new integer field of type “Commission” for an object of type “Opportunity” stored in data store 115. The field type “Commission” may not be identified as a field in any object type definition 230 or metadata module 235 maintained by client application 135 or maintained by server 110. Server 110 may update the object type definition 230 corresponding to object type “Opportunity” and one or more corresponding metadata modules 235 maintained by client application 135. Specifically, the update to object type “Opportunity” and one or more corresponding metadata modules 235 includes a new integer field of type “Commission.” Data store 115 and client application 135 may store values ​​for the field of type “Commission” to reflect the addition of the new field of type “Commission.” Client application 135 may also retrieve and display values ​​corresponding to the field “Commission” on a user interface.

[0041] In one embodiment, server 110 may receive a request to create a new type of object that differs from the type of any objects stored in data store 115 and / or client application 135. In response to the request to create a new type of object, server 110 may (a) create a new object type definition 230 and (b) create one or more new metadata modules 235 corresponding to the new object type. The object type definition 230 may include one or more data fields to be included in an object of the new type, and the one or more metadata modules 235 may specify various subsets of the one or more data fields to be included in an object of the new type. Server 110 may synchronize the new object type definition 230 and the new one or more metadata modules 235 with client application 135 by updating the data control model of client application 135. Thus, server 110 and client application 135 may use the object type definition 230 and the metadata modules 235 to define the new object type. Server 110 may add the new object type to the set of object types defined by server 110 and used by client application 135.

[0042] Continuing with the example above, server 110 creates a new object of type NetworkingEvent. The request may also include three fields, "Date", "Time", and "Date", as fields of an object of type NetworkingEvent. Both the client application 135 and the server 110 may specify an object that defines any object of type NetworkingEvent. In response to receiving a request, the server 110 may not include an object type definition 230 or a metadata module 235. The object type definition 230 and one or more metadata modules 235 corresponding to the object type NetworkingEvent may be generated. and one or more metadata modules 235 may identify at least three fields: "date," "time," and "location." The server 110 uses the object type definition 230 and one or more metadata modules 235 to provide a definition of the object type NetworkingEvent. The client application 135 may also create an object of type NetworkingEvent and send the event to the client application 135. The object may be sent to the server 110 for synchronization.

[0043] 4. Exemplary Embodiments Detailed examples are provided below for clarity. The components and / or operations described below should be understood as examples that may not be applicable to a particular embodiment. Therefore, the components and / or operations described below should not be construed as limiting the scope of any of the appended claims.

[0044] 4.1 Modifying the Polymorphic Data Model 3 shows a block diagram illustrating an example set of operations 300 for updating an object type definition in accordance with one or more embodiments. One or more of the operations shown in FIG. 3 may be modified, rearranged, or omitted altogether. Thus, the particular sequence of operations shown in FIG. 3 should not be construed as limiting the scope of one or more embodiments.

[0045] In operation 305, the client application 135 may receive the first object type definition 230 from the data store 115. The first object type definition 230 may be provided to the client application 135 from the server 110 that hosts the data store 115. The object type definition 230 may be received by the client device 130 on which the application 135 executes via the network 120. The first object type definition 230 may define a first object type to be used in the data control model 200 to control the functionality of the client application 135. The first object type definition 230 may define one or more data fields of the first object type. Each defined data field may include a data field name and a data field value. As an example, the object type may be an "opportunity," e.g., a sales opportunity. The object type "opportunity" may include a number of data fields, e.g., a "Customer Name" field and a "Customer ID" field. and Customer Phone Number fields. The object type definition 230 may be defined.

[0046] At operation 310, a first object of a first object type may be processed according to the received first object type definition 230. For example, the client application 135 may generate a persistent entity 210 to represent an instance of the first object according to the first object type definition 230. The generated persistent entity 210 may include a unique identifier 215 that uniquely identifies the first object within the polymorphic entity 205 that represents the schema used by the client application 135. The generated persistent entity 210 may also include an object type definition 220 that is based on a copy of the first object type definition 230 on which the generated persistent entity 210 is based. The persistent entity 210 may also include one or more data fields with associated data values ​​225 according to the object type definition 220. As another example, a user interface of the client application 135 may display one or more data field values ​​of the first object. Persistent entity 210 may also execute one or more methods associated with the class defined by object type definition 220 to operate on the first object represented by persistent entity 210 .

[0047] At operation 315, the client application 135 may receive an update of the first object type definition 230 from the data store 115. The update may include a second object type definition 230. The second object type definition 230 may define a second object type to be used in the data control model 200 that controls the functionality of the client application 135. The second object type definition 230 may define one or more data fields of the second object type. Each defined data field may include a data field name and a data field value. As an example, the object type may be "Warehouse." The type "Warehouse" contains a number of data fields, e.g., a "Warehouse Address" field and a "Warehouse Phone Number" field. As another example, the second object type definition 230 may be an updated version of the first object type definition 230 and may replace the first object type definition 230 in the data control model 200 of the client application 135. The second object type definition 230 may be an "opportunity," e.g., a sales opportunity. The updated second object type "opportunity" may include multiple data fields, e.g., a "customer name" field, a "customer phone number" field, and a "customer budget" field. The second object type definition 230 may be defined to include additional data fields and values ​​not included in the first object type definition 230. In this example, the second object type definition 230 includes additional data fields and values ​​not included in the first object type definition 230.

[0048] At operation 320, a second object of a second object type may be processed according to the received second object type definition 230. For example, The application 135 may generate a persistent entity 210 to represent an instance of the second object according to the second object type definition 230. The generated persistent entity 210 may include a unique identifier 215 that uniquely identifies the second object within the polymorphic entity 205 that represents the schema used by the client application 135. The generated persistent entity 210 may also include an object type definition 220 that is based on a copy of the second object type definition 230 on which the generated persistent entity 210 is based. The persistent entity 210 may also include one or more data fields with associated data values ​​225 according to the object type definition 220. As another example, the user interface of the client application 135 may display one or more data field values ​​of the second object. The persistent entity 210 may also execute one or more methods associated with the class defined by the object type definition 220 to operate on the second object represented by the persistent entity 210. As another example, if second object type definition 230 is an updated version of first object type definition 230 and replaces first object type definition 230 in data control model 200 of client application 135, persistent entity 210 representing a first object of the first object type may be updated to include object type definition 220 based on a copy of second object type definition 230 and to represent an instance of a second object of the second object type accordingly. Persistent entity 210 may also be updated to include one or more additional data fields with associated data values ​​225 in accordance with the updated object type definition 220.

[0049] In operation 325, client application 135 may send the data field values ​​of the second object to data store 115. For example, client application 135 may send the value of "Warehouse Phone Number" if the second object type is "Warehouse," and thereby update the "Warehouse Phone Number" stored for the "Warehouse" object in data store 115. As another example, client application 135 may update the value of "Customer Budget" stored in an "Opportunity" object in data store 115. Client application 135 may send the value of "Customer Budget" if the second object type is "Opportunity" with an updated list of data fields compared to the first object type.

[0050] At operation 330, the client application 135 may receive one or more metadata modules 235 from the data store 115. The metadata modules 235 may define subtypes of the second object type defined by the second object type definition 230. For example, the first metadata module 235 may define a full standard subtype of the “Opportunity” object type that includes a “Customer Name” field, a “Customer Phone Number” field, and a “Customer Budget” field. The second metadata module 235 may define a subset subtype of the “Opportunity” object type that includes a “Customer Name” field and a “Customer Phone Number” field. The third metadata module 235 may define a list subtype of the “Opportunity” object type that includes only the “Customer Name” field. A method for the “Opportunity” object type may download a list of “Opportunity” objects according to the list subtype metadata module 235 to minimize data transmission overhead and data storage overhead at the client device 130. If only the “Customer Name” field needs to be presented in the user interface of the client application 135, a full standard representation of the “Opportunity” object may not be necessary, and a list subtype may be more efficient. Another method for the "Opportunity" object type may be to download all standard representations of the selected "Opportunity" object according to the All Standard Subtypes metadata module 235. One "Opportunity" object in the list of "Opportunity" objects may be added to the selected "Opportunity" object If all of the data fields are selected to be viewed and / or edited, the full standard representation of the "Opportunity" object may be required and the List subtype may be insufficient.

[0051] In operation 340, the client application 135 may make a determination as to whether a new object created according to the second object type definition 230 is a first subtype, for example, created according to a list subtype of the “Opportunity” object type, or a second subtype, for example, created according to a full standard subtype of the “Opportunity” object type.

[0052] At operation 345, if the new object is determined to correspond to a first subtype of the second object type definition 230 at operation 340, the client application 135 may fetch values ​​of data fields corresponding to the first subtype from the data store 115. For example, if the first subtype of the “Opportunity” object type is a list subtype, the client application 135 may fetch values ​​of the “Customer Name” data field from the data store 115.

[0053] At operation 350, if the new object is determined to correspond to a second subtype of the second object type definition 230 at operation 340, the client application 135 may fetch values ​​of data fields corresponding to the second subtype from the data store 115. For example, if the second subtype of the “Opportunity” object type is an All Standard subtype, the client application 135 may fetch values ​​of a “Customer Budget” data field from the data store 115.

[0054] At act 355, client application 135 may process the values ​​of the data fields fetched in either act 345 or act 350. For example, client application 135 may display the values ​​of the fetched data fields in a user interface of client application 135. Client application 135 may perform mathematical calculations on the values ​​of the fetched data fields and display the results of the mathematical calculations in a user interface of client application 135.

[0055] In act 360, client application 135 may cause the value of the data field processed in act 355 to be updated in data store 115. Client application 135 may execute a method defined by second object type definition 230 represented in object type definition 220 of persistent entity 210. The executed method may include sending an HTTP request to data store 115 to update the value of the data field fetched in one of acts 345 and 350 according to a result of processing the value of the data field fetched in act 355.

[0056] 4 shows a block diagram illustrating an example set of operations 400 for updating an object type definition in accordance with one or more embodiments. One or more of the operations shown in FIG. 4 may be modified, rearranged, or omitted altogether. Thus, the particular sequence of operations shown in FIG. 4 should not be construed as limiting the scope of one or more embodiments.

[0057] At operation 405, the client application 135 may receive a first database schema, e.g., a data control model 200 that controls the functionality of the client application 135, from the data store 115. The first database schema may include: The first database schema may be received from the server 110 hosting the data store 115 by a client device 130 on which a client application 135 executes via the network 120. The first database schema may include a first object type definition 230 that defines a first object type. The first object type definition 230 may define one or more data fields of the first object type. Each defined data field may include a data field name and a data field value. As an example, the object type may be an "opportunity," e.g., a sales opportunity. The object type "opportunity" may be defined by the first object type definition 230 to include multiple data fields, e.g., a "customer name" field and a "customer phone number" field. The first database schema may also include one or more metadata modules 235 that each define a view of the first object type defined by the first object type definition 230. Each of the one or more metadata modules 235 may specify a different subset of data fields included in the full standard representation of the first object type to be included in the respective view. As an example, one view defined by one of the metadata modules 235 may specify that only the "Customer Name" field should be included from the various fields specified by all standard "Opportunity" object types, while another view defined by another of the metadata modules 235 may specify that both the "Customer Name" field and the "Customer Phone Number" field should be included from the various fields specified by all standard "Opportunity" object types.

[0058] At operation 410, a first object of a first object type may be processed according to the received first database schema. For example, the client application 135 may generate a persistent entity 210 to represent an instance of the first object according to the first object type definition 230. The generated persistent entity 210 may include a unique identifier 215 that uniquely identifies the first object within the polymorphic entity 205 that represents the first database schema used by the client application 135. The generated persistent entity 210 may also include an object type definition 220 that is based on a copy of the first object type definition 230 on which the generated persistent entity 210 is based. The persistent entity 210 may also include one or more data fields with associated data values ​​225 according to the object type definition 220. As another example, a user interface of the client application 135 may display one or more data field values ​​of the first object. Persistent entity 210 may also execute one or more methods associated with the class defined by object type definition 220 to operate on the first object represented by persistent entity 210 .

[0059] At operation 415, the client application 135 may receive an update of the first database schema from the data store 115. The update of the first database schema may include a second database schema that is different from the first database schema. The update may include a second object type definition 230. The second object type definition 230 may define a second object type to be used in the data control model 200 that controls the functionality of the client application 135. The second object type definition 230 may define one or more data fields of the second object type. Each defined data field may include a data field name and a data field value. As an example, the object type may be "warehouse." The object type "warehouse" may be defined by the second object type definition 230 to include multiple data fields, for example, a "warehouse address" field and a "warehouse phone number" field. As another example, the second object type definition 230 may be an updated version of the first object type definition 230 and may be updated by the client. The second object type definition 230 may replace the first object type definition 230 in the data control model 200 of the application 135. The second object type definition 230 may be an "opportunity," e.g., a sales opportunity. The updated second object type "opportunity" may be defined by the second object type definition 230 to include multiple data fields, e.g., a "customer name" field, a "customer phone number" field, and a "customer budget" field. In this example, the second object type definition 230 includes additional data fields and values ​​not included in the first object type definition 230.

[0060] At operation 420, the second object of the second object type may be processed according to the received second database schema. For example, the client application 135 may generate a persistent entity 210 to represent an instance of the second object according to the second object type definition 230. The generated persistent entity 210 may include a unique identifier 215 that uniquely identifies the second object within the polymorphic entity 205 that represents the schema used by the client application 135. The generated persistent entity 210 may also include an object type definition 220 that is based on a copy of the second object type definition 230 on which the generated persistent entity 210 is based. The persistent entity 210 may also include one or more data fields with associated data values ​​225 according to the object type definition 220. As another example, a user interface of the client application 135 may display one or more data field values ​​of the second object. Persistent entity 210 may also execute one or more methods associated with the class defined by object type definition 220 to operate on a second object represented by persistent entity 210. As another example, if second object type definition 230 is an updated version of first object type definition 230 and replaces first object type definition 230 in data control model 200 of client application 135, persistent entity 210 representing a first object of the first object type may be updated to include object type definition 220 based on a copy of second object type definition 230 and to represent an instance of a second object of the second object type accordingly. Persistent entity 210 may also be updated to include one or more additional data fields with associated data values ​​225 in accordance with the updated object type definition 220.

[0061] At operation 425, the client application 135 may send the data field values ​​of the second object to the data store 115. For example, the client application 135 may send the value of "Warehouse Phone Number" if the second object type is "Warehouse," which may update the "Warehouse Phone Number" stored for the "Warehouse" object in the data store 115. As another example, the client application 135 may send the value of "Customer Budget" if the second object type is "Opportunity," which has an updated list of data fields compared to the first object type, which may update the value of "Customer Budget" stored for the "Opportunity" object in the data store 115.

[0062] At operation 430, the client application 135 may receive one or more metadata modules 235 from the data store 115. The metadata modules 235 may define subtypes of the second object type defined by the second object type definition 230. For example, a first metadata module 235 may define a full standard subtype of the "Opportunity" object type that includes a "Customer Name" field, a "Customer Phone Number" field, and a "Customer Budget" field. A second metadata module 235 may define a subset subtype of the "Opportunity" object type that includes a "Customer Name" field and a "Customer Phone Number" field. A third metadata module 235 may define a list subtype of the "Opportunity" object type that includes only the "Customer Name" field. A method for the "Opportunity" object type may download a list of "Opportunity" objects according to the list subtype metadata module 235 when only the "Customer Name" field needs to be presented in the user interface of the client application 135 to minimize data transmission and data storage overhead at the client device 130. Another method for the "Opportunity" object type may download a full standard representation of a selected "Opportunity" object according to the full standard subtype metadata module 235 when an "Opportunity" object in a list of "Opportunity" objects is selected to view and / or edit all of the data fields of the selected "Opportunity" object.

[0063] In operation 440, the client application 135 may make a determination as to whether the new object created according to the second object type definition 230 is a first subtype, for example, created according to a list subtype of the “Opportunity” object type, or a second subtype, for example, created according to all standard subtypes of the “Opportunity” object type.

[0064] At operation 445, if the new object is determined to correspond to a first subtype of the second object type definition 230 at operation 440, the client application 135 may fetch values ​​of data fields corresponding to the first subtype from the data store 115. For example, if the first subtype of the “Opportunity” object type is a list subtype, the client application 135 may fetch values ​​of the “Customer Name” data field from the data store 115.

[0065] At operation 450, if the new object is determined to correspond to a second subtype of the second object type definition 230 at operation 440, the client application 135 may fetch values ​​of data fields corresponding to the second subtype from the data store 115. For example, if the second subtype of the “Opportunity” object type is an All Standard subtype, the client application 135 may fetch values ​​of the “Customer Budget” data field from the data store 115.

[0066] At operation 455, client application 135 may process the values ​​of the data fields fetched in either operation 445 or operation 450. For example, client application 135 may display the values ​​of the fetched data fields in a user interface of client application 135, or client application 135 may perform mathematical calculations on the values ​​of the fetched data fields and display the results of the mathematical calculations in a user interface of client application 135.

[0067] At act 460, client application 135 may cause the value of the data field processed at act 455 to be updated in data store 115. Client application 135 may execute a method defined by second object type definition 230 represented in object type definition 220 of persistent entity 210. The executed method may include sending an HTTP request to data store 115 to update the value of the data field fetched at one of acts 445 and 450 according to a result of processing the value of the data field fetched at act 455.

[0068] 4.2 Recursive Data Traversal Model Often application data about the client application 135 and features are desirably configurable on the fly for various business purposes and improved user experience. Run-time extensions may facilitate application data and features being seamlessly configurable via client device 130 or server 110. Additionally, offline access may facilitate application data and features being available in client application 135 when client device 130 is unable to connect to server 110 via network 120. If a user attempts to define flows for accessing application data or functionality within client application 135 at run time but the corresponding design-time entities are not available on client device 130, the user's use of client application 135 may be limited.

[0069] As an example, this may be the case when customers of a client application 135 across various industries request detailed information about configurations specific to their various business workflows through a synchronization process. One embodiment addresses this issue using an object-agnostic data traversal model as part of the definition file for the client application 135. The object-agnostic data traversal model may feature polymorphic behavior that facilitates runtime changes, acting in response to on-the-fly changes to the client application 135 definition. One embodiment of this object-agnostic data traversal model facilitates the client application 135 to translate graph configurations that may change at runtime in real time, requesting data from the data store 115 hosted on the server 110 through a traversal mechanism during seamless connection or disconnection to the data store 115 hosted on the server 110 to provide access to application data and features defined either at design time or at runtime.

[0070] The client application 135 may include, interpret, and use a graph configuration model to access application data and features defined either at design time or run time. The graph configuration model may be object-independent and may include unique identifiers specified on the defined entities. These unique identifiers may be used in conjunction with metadata properties defined on the entities to issue subsequent requests. Each feature may be persisted as an abstract object definition under the identifier and may subsequently be retrieved when an action specifying a matching unique identifier is invoked. Data retrieval relationships between various entities in the graph configuration model may be specified in metadata properties according to the unique identifiers of the corresponding entities. The data retrieval relationships may be mappings that statically link various object types represented by corresponding entities. The data retrieval relationships may be virtually any mapping used by the client application 135 to determine which records should be retrieved based on a first object type. The data retrieval relationships may identify a second object type as a function of the first object type. The client application 135 may then retrieve records of this second object type from the data store 115 on the server 110. Multiple modes of cached data retrieval can be supported, either using a URI or a runtime index.

[0071] The client application 135 may translate the configuration graph, which may change at runtime, in real time to request data from the data store 115. The configuration graph may facilitate the client application 135 to efficiently and optimally construct requests to fetch data from the data store 115. The configuration graph may be segmented into metadata that conforms to a standard schema and may be stored in memory as a collection of abstract entities identified by unique qualifiers defined for the abstract entities. The qualifiers may be used in conjunction with properties defined for the entity to request information. The request for data may be by recursive data traversal and may provide access to data and features defined either at client application 135 design time or at client application 135 runtime while connected to or disconnected from data store 115. Data may be cached on client device 130 prior to user access, thereby optimizing the user experience in real time. Responses to requests may be received and persisted in data storage on client device 130.

[0072] Client applications 135 may interpret and use the graph composition model to access data about features defined either at design time or at run time for the client application 135. Unique identifiers specified for entities defined by the object agnostic model may be used along with metadata properties defined on the entities to issue subsequent requests. Each feature may be persisted as an abstract object definition under the identifier and subsequently retrieved when an action specifying the matching unique identifier is invoked.

[0073] 5 shows a block diagram illustrating a configuration graph 500 showing relationships between entities 510 and related entities 520, according to one or more embodiments. Each entity 510 may have data retrieval relationships 515 with one or more related entities 520. Similarly, each related entity 520 may have data retrieval relationships 525 with one or more other related entities 520. The configuration graph 500 may be stored in a configuration data file or in a data structure stored in memory.

[0074] 6 shows a block diagram illustrating components of an entity 600 in a configuration graph according to one or more embodiments. Entity 600 may be one embodiment of entity 510 shown in FIG. 5. Entity 600 may include a unique identifier 610, data 620, a type definition 630, pointers to one or more related entities 640, and various query properties 650. Unique identifier 610 may correspond to the unique identifier 215 of a persistent entity 210 corresponding to entity 600 if entity 600 is persisted in client application 135 and / or client device 130. Data 620 may correspond to a data value 225 of the corresponding persistent entity 210, and type definition 630 may correspond to the type definition 220 of the corresponding persistent entity 210.

[0075] Related entities 640 may include a list of unique identifiers 710 (see FIG. 7) associated with one or more related entities 700. Related entities 640 may be related to entity 600 according to any of a number of different criteria, which may be specified in query properties 650. Query properties 650 may also specify how related entities 640 should be ordered in the list of results when related entities 640 are queried in data store 115 of server 110.

[0076] 7 shows a block diagram illustrating components of a related entity 700 in a configuration graph according to one or more embodiments. The related entity 700 may be one embodiment of the related entity 520 shown in FIG. 5. The related entity 700 may include a unique identifier 710, data 720, a type definition 730, pointers to one or more other related entities 740, and various query properties 750. The unique identifier 710 may be used to identify the related entity 700 when it is persisted in the client application 135 and / or the client device 130. The data 720 may correspond to the data values ​​225 of the corresponding persistent entity 210, and the type definition 730 may correspond to the type definition 220 of the corresponding persistent entity 210.

[0077] A related entity 740 may include a list of unique identifiers 710 associated with one or more other related entities 700. The related entities 740 may be related to the related entity 700 according to any of several different criteria, which may be specified in a query property 750. The query property 750 may correspond to the results of a query executed on the entity 600 to return one or more related entities 640 according to a query property 650 associated with the executed query. The query property 750 may also specify how the related entities 740 should be ordered in the list of results when the related entities 740 are queried in the data store 115 of the server 110. The query property 750 also includes the ParentID or unique identifier 710 of the entity 600 associated as a parent to the related entity 700, and the cardinality or number of related entities 700 that match a given query criteria with the related entity 700.

[0078] FIG. 8 shows a block diagram illustrating an example set of operations 800 for updating a data cache in accordance with one or more embodiments. The set of operations 800 may be performed by a client application 135 on a client device 130, as shown in FIG. 1. One or more of the operations shown in FIG. 8 may be modified, rearranged, or omitted altogether. Thus, the particular sequence of operations shown in FIG. 8 should not be construed as limiting the scope of one or more embodiments. Detailed examples are provided below for clarity. The components and / or operations described below should be understood as a specific example that may not be applicable to a particular embodiment. Thus, the components and / or operations described below should not be construed as limiting the scope of any of the appended claims. In various embodiments, the operations 800 may be performed using the systems and components described above with reference to FIGS. 1-9.

[0079] A configuration graph, e.g., configuration graph 500, may be stored in a data file or an in-memory data structure. The configuration graph may define a subset of data to be retrieved from data store 115 and stored on client device 130 by client application 135. The client device 130 may include much less memory than the memory capacity of data store 115, and the data bandwidth available on network 120 for transmitting data from data store 115 to client device 130 may be limited. The data defined in a configuration graph (e.g., configuration graph 500) may include entities (e.g., entity 510) and related entities (e.g., related entity 520) corresponding to persistent entities 210 described herein with reference to FIG. 2. The configuration graph may also define characteristics of client application 135, such as queries to be performed on data stored in data store 115 to retrieve data that matches various defined criteria. The data and applications in the configuration graph may include information stored in metadata. Based on the metadata, the client application 135 may identify related entities 520, generate queries regarding the related entities 520 identified in the metadata using the values ​​of the entities 510, and then retrieve the entities 510 and the related entities 520 from the data store 115.

[0080] As an example, entity 510 in configuration graph 500 is of object type " Regarding the first object type, there is a type definition 630 for "Product." The “product” object type may relate to one or more products offered by a company that a seller using client application 135 on client device 130 will visit to make a sale. Configuration graph 500 may include a query in the metadata along with query property 650 to search and retrieve all second object types having type definitions 630 for object type “opportunity” in data store 115 that match specified query property 650 for specified products offered by the seller's company. The “opportunity” object type may relate to one or more sales opportunities for specified products offered by a company. A sales opportunity may include information such as the name, phone number, address, and telephone number of a contact person, the product desired for purchase, the expected number of units required, and the expected timeframe for delivery. Client application 135 may analyze the relationship between the specified product and the associated sales opportunity as a data retrieval relationship associated with the first object type and stored in the metadata (operation 810). In this example, the first object type may be a “product” object type.

[0081] After client application 135 analyzes the data retrieval relationships, client application 135 may determine whether there are records to retrieve from data store 115 based on the records of the first object type (operation 820). Following the analysis of operation 810 in this example, client application 135 may determine that there are sales opportunities to retrieve from data store 115 based on specified products offered by the company.

[0082] In the described example, client application 135 may begin preparations to perform a query against data store 115 to retrieve all sales opportunity records associated with a company's products that a salesperson may need during a sales call. As one of these preparation steps, client application 135 may identify the product name of each of one or more products for which sales opportunities will be retrieved from data store 115. In other words, client application 135 may identify one or more values ​​from one or more records for a first object type, e.g., a "product" object type, that correspond to the product name field of the first object type (operation 830).

[0083] The client application 135 may then generate one or more sets of queries using one or more product names for each of one or more products for which sales opportunities will be retrieved from the data store 115. These queries may be generated based on query properties 650 in the entities 600 corresponding to the products. The sets of queries may be generated to retrieve related entities 640 associated with a particular entity 600. For example, two or more sets of queries may be generated, such as one query for one product name and another query for another product name. In other words, the client application 135 may generate one or more sets of queries to retrieve first and second subsets of the second set of records of the second object type (operation 840). The act of generating the one or more queries may include an act of generating one or more URIs representing the queries. The first and second subsets of the second set of records of the second object type may include first and second values, respectively, related to a second field of the second object type. For example, the first and second subsets of sales opportunity records may include a first product name and a second product name, respectively, that are related to the product name field of the corresponding subset of sales opportunities. A set of queries may be performed to retrieve from the data store 115 the first subset of sales opportunities related to the first product name and the second subset of sales opportunities related to the second product name. Client application 135 may then execute a set of one or more queries to obtain a first subset and a second subset of the second set of records of the second object type (act 850).

[0084] After executing the query, client application 135 may store the data retrieved from data store 115 on client device 130 by updating a cache in client application 135 with the first and second subsets of the second set of records of the second object type (operation 860). For example, client application 135 may store sales opportunities associated with products whose names were identified in the query executed on data store 115 locally in a data cache on client device 130.

[0085] Table 1 below illustrates an exemplary configuration graph 500 represented by records about products and related sales opportunities to be retrieved from data store 115 following execution of a query on the product name of a specified product in operation 850. The product records represent data stored in data store 115 that should be accessed by the query.

[0086] As shown in Table 1, product records have a product name field value that matches a corresponding product name field in a corresponding sales opportunity record. A query for sales opportunity records associated with a particular product may search for a product name field that has a particular product name value that matches the product name value of the particular product with which the sales opportunity record is associated. A relationship between a product and a sales opportunity may be established, for example, whenever a potential customer expresses interest in a product and that interest is captured in data store 115 as an entry in the relevant sales opportunity record associated with the customer. The interest may be captured by data entry from a seller, a website form, a handwritten information card, etc.

[0087] Table 1. Exemplary configuration graph 500 representing a product record with statically linked related sales opportunity records

[0088] [Table 1] TIFF0007789830000002.tif127152

[0089] Table 2 below shows a similar example of a configuration graph 500 including records about products and related sales opportunities to be retrieved from data store 115 following execution of a query on the product name of the specified product in operation 850, except that the product records are stored using dynamically linked relationships between the related entities. In contrast to the statically linked relationships shown in Table 1, where relationships are identified by the names of fields shared between entities and the related entities, the dynamically linked relationships in Table 2 are established by a dynamic link data structure between entities and the related entities. As relationships change, client application 135 may modify the links in the data structure of the data cache loaded on client device 130. Client application 135 may also execute configuration graph 500 to update the data cache loaded on client device 130 from data stored in data store 115.

[0090] Table 2. Exemplary composition graph 500 including product records with dynamically linked related sales opportunity records

[0091] [Table 2] TIFF0007789830000004.tif127152

[0092] In one embodiment, configuration graph 500 may include all sales opportunities for a geographic area that a seller intends to visit on a sales trip associated with the products the seller is selling. Configuration graph 500 may automatically update client device 130 with information the seller will need for an upcoming sales trip, without the seller having to manually do so. A seller may load a data file containing configuration graph 500 into client application 135 before a sales trip to automatically update the data cache of client device 130 before the seller's sales trip.

[0093] In various embodiments, the configuration graph 500 may facilitate data stored locally on the client device 130 being automatically updated as needed and in advance of when expected, thereby avoiding problems with slow or inaccessible access to the data store 115 by the client application 135 when the data is needed.

[0094] In various embodiments, the configuration graph 500 is stored in memory within the client application 135, such that each time a merchant signs up to the client application 135, the configuration graph 500 is traversed and the data cache of the client device 130 is updated according to the current data stored in the data store 115 before the merchant begins using the client application 135.

[0095] In various embodiments, a graph corresponding to an entity 510 in the configuration graph 500 Each time a persistent entity 210 is updated in the client application 135, the configuration graph 500 may be traversed to refresh or update any entities 600 and / or related entities 640 affected by the update of the persistent entity 210 with data downloaded from the data store 115.

[0096] The configuration graph 500 facilitates efficient updating of data remaining on the client device 130 from data downloaded from the data store 115. This is important and useful considering that the client device 130 contains significantly less memory and storage space for data than the data store 115, and the network 120 between the client device 130 and the server 110 hosting the data store 115 has limited bandwidth and is often unavailable.

[0097] 5. Computer Networks and Cloud Networks In one or more embodiments, a computer network provides connectivity between a set of nodes. These nodes may be local and / or remote from one another. These nodes are connected by a set of links. Examples of links include coaxial cable, bare twisted cable, copper cable, optical fiber, and virtual links.

[0098] A subset of nodes implements computer networks. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of nodes uses computer networks. Such nodes (also called "hosts") may run client processes and / or server processes. A client process makes a request for a computing service (e.g., running a particular application and / or storing a particular amount of data). A server process responds by performing the requested service and / or returning corresponding data.

[0099] A computer network may be a physical network including physical nodes connected by physical links. A physical node is any digital device. A physical node may be a function-specific hardware device such as a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Additionally or alternatively, a physical node may be a general-purpose machine configured to run various virtual machines and / or applications that perform their respective functions. A physical link is a physical medium connecting two or more physical nodes. Examples of links include coaxial cable, unshielded twisted cable, copper cable, and optical fiber.

[0100] A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (e.g., a physical network). Each node in the overlay network corresponds to a respective node in the underlying network. Thus, each node in the overlay network is associated with both an overlay address (for addressing the overlay node) and an underlay address (for addressing the underlay node that realizes the overlay node). An overlay node may be a digital device and / or a software process (e.g., a virtual machine, an application instance, or a thread). The links connecting overlay nodes are realized as tunnels through the underlying network. The overlay nodes at both ends of the tunnel are ,The underlying multi-hop path between the overlay nodes is treated as a single logical link.,Tunneling is performed by encapsulation and decapsulation.

[0101] In some embodiments, a client may be local and / or remote to a computer network. A client may access a computer network through a private network or another computer network, such as the Internet. A client may communicate a request to the computer network using a communication protocol, such as HTTP. The request may be transmitted via a client interface (e.g., a web browser), a program interface, or an application programming interface (API). communicated through the interface.

[0102] In one embodiment, a computer network provides connectivity between clients and network resources. The network resources include hardware and / or software configured to run server processes. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. The network resources are shared among multiple clients. The clients request computing services from the computer network independently of each other. The network resources are dynamically allocated to requests and / or clients on an on-demand basis. The network resources allocated to each request and / or client may be scaled up or down based on, for example, (a) the computing services requested by a particular client, (b) the aggregated computing services requested by a particular tenant, and / or (c) the aggregated computing services requested from the computer network. Such a computer network may also be referred to as a "cloud network."

[0103] In some embodiments, a service provider offers a cloud network to one or more end users. Platform-as-a-Service (PaaS) Various service models can be enabled by cloud networks, including, but not limited to, SaaS, and Infrastructure-as-a-Service (IaaS). In SaaS, a service provider offers end users the ability to use the service provider's applications running on network resources. In PaaS, a service provider offers end users the ability to deploy custom applications on network resources. Custom applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, a service provider offers end users the ability to provision processing, storage, network, and other basic computing resources provided by the network resources. Any application, including an operating system, can be deployed on the network resources.

[0104] In an embodiment, a computer network may enable a variety of deployment models, including, but not limited to, private cloud, public cloud, and hybrid cloud. In a private cloud, network resources are provisioned for the exclusive use of a specific group of one or more entities (as used herein, the term "entity" refers to a business, organization, person, or other entity). The network resources may be local and / or remote to the premises of the specific group of entities. In a public cloud, cloud resources are distributed among multiple entities ("tenants" or "customers") that are independent of one another. A computer network and its network resources are provisioned for a tenant (also referred to as a "customer"). The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network is sometimes referred to as a "multi-tenant computer network." Several tenants may use the same particular network resource at different times and / or at the same time. The network resource may be local and / or remote to the tenant's premises. In a hybrid cloud, the computer network includes a private cloud and a public cloud. An interface between the private cloud and the public cloud enables data and application portability. Data stored in the private cloud and data stored in the public cloud may be exchanged through the interface. Applications implemented in the private cloud and applications implemented in the public cloud may have dependencies on each other. Calls from an application in the private cloud to an application in the public cloud (and vice versa) may be made through the interface.

[0105] In one embodiment, tenants of a multi-tenant computer network are independent of one another. For example, the business or operations of one tenant may be separate from the business or operations of another tenant. Different tenants may require different network requirements from the computer network. Examples of network requirements include processing speed, data storage, security requirements, performance requirements, throughput requirements, latency requirements, resilience requirements, Quality of Service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may need to fulfill the different network requirements required by different tenants.

[0106] In one or more embodiments, tenant isolation is implemented in a multi-tenant computer network to ensure that applications and / or data of different tenants are not shared with each other. Various tenant isolation approaches may be used.

[0107] In one embodiment, each tenant is associated with a tenant ID. Each network resource in a multi-tenant computer network is tagged with a tenant ID. A tenant is granted access to a particular network resource only if the tenant and the particular network resource are associated with the same tenant ID.

[0108] In one embodiment, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with a tenant ID. Additionally or alternatively, each data structure and / or dataset stored by the computer network is tagged with a tenant ID. A tenant is granted access to a particular application, data structure, and / or dataset only if the tenant and the particular application, data structure, and / or dataset are associated with the same tenant ID.

[0109] As one example, each database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only the tenant associated with the corresponding tenant ID may access the data in a particular database. As another example, each entry in a database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only the tenant associated with the corresponding tenant ID may access the data in a particular entry. However, a database may be shared by multiple tenants.

[0110] In one embodiment, the subscription list indicates which tenants have authorization to access which applications. For each application, a list of tenant IDs of tenants authorized to access the application is stored. A tenant is granted access to a particular application only if the tenant's tenant ID is included in the subscription list corresponding to that particular application.

[0111] In one embodiment, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are separated into tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, packets from any source device in a tenant overlay network can be sent only to other devices within the same tenant overlay network. To prohibit any transmission from a source device on a tenant overlay network to a device in another tenant overlay network, an encapsulation tunnel is used. Specifically, a packet received from a source device is encapsulated within an outer packet. The outer packet is sent from a first encapsulation tunnel endpoint (communicating with the source device in the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with a destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer packet to obtain the original packet sent by the source device. The original packet is sent from the second encapsulation tunnel endpoint to a destination device in the same specific overlay network.

[0112] 6. Other; Extensions Embodiments are directed to systems that include one or more devices that include a hardware processor and are configured to perform any of the operations described herein and / or recited in any of the appended claims.

[0113] In an embodiment, a non-transitory computer-readable storage medium comprises instructions that, when executed by one or more hardware processors, cause any of the operations described herein and / or recited in any of the claims.

[0114] Any combination of features and functionality described herein may be used in accordance with one or more embodiments. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Accordingly, the specification and accompanying drawings should be considered in an illustrative rather than a limiting sense. The sole and exclusive indication of the scope of the invention, and what is intended by the applicant to be the scope of the invention, is the literal and equivalent scope of the set of claims issuing from this application in the specific form in which such claims arise, including any subsequent amendments.

[0115] 7. Hardware Overview According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices, which may be hardwired to perform the techniques or may include one or more application-specific integrated circuits (ICs) permanently programmed to perform the techniques. It may include digital electronic devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a network processing unit (NPU), or Such special-purpose computing devices may also include one or more general-purpose hardware processors that are programmed to perform these techniques according to program instructions in firmware, memory, other storage devices, or a combination thereof. Custom hardwired logic, ASICs, FPGAs, or NPUs may be combined with custom programming to perform these techniques. The dedicated computing device may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device incorporating hardwired and / or program logic to implement these techniques.

[0116] 9 is a block diagram illustrating a computer system 900 upon which one embodiment of the present invention may be implemented. Computer system 900 includes a bus 902 or other communication mechanism for communicating information, and a hardware processor 904 coupled with bus 902 for processing information. Hardware processor 904 may be, for example, a general-purpose microprocessor.

[0117] Computer system 900 also includes a main memory 906, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 902 for storing instructions and information to be executed by processor 904. Main memory 906 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 904. Such instructions, when stored on a non-transitory storage medium accessible to processor 904, render computer system 900 a special-purpose machine customized to perform the operations specified in the instructions.

[0118] Computer system 900 further includes a read only memory (ROM) 908 or other static storage device coupled to bus 902 for storing static information and instructions for processor 904. A storage device 910, such as a magnetic disk or optical disk, is provided and coupled to bus 902 for storing information and instructions.

[0119] Computer system 900 may be coupled via bus 902 to a display 912, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 914, including alphanumeric and other keys, is coupled to bus 902 for communicating information and command selections to processor 904. Another type of user input device is a cursor control device 916, such as a mouse, trackball, or cursor direction keys, for communicating directional information and command selections to processor 904 and for controlling cursor movement on display 912. The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), allowing the device to specify a position in a plane.

[0120] Computer system 900 may implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, when combined with the computer system, makes computer system 900 a special-purpose machine or programs it to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 900 in response to processor 904 executing one or more sequences of one or more instructions contained in main memory 906. Such instructions may be read into main memory 906 from another storage medium, such as storage device 910. Execution of the sequences of instructions contained in main memory 906 causes processor 904 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0121] The term "storage medium" as used herein refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 910. Volatile media include dynamic memory, such as main memory 906. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge, content-addressable memory (CAM), and ternary content-addressable memory (TCAM).

[0122] Storage media are distinct from but may be used in conjunction with transmission media. Transmission media involves transferring information between storage media. For example, transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise bus 902. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0123] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 904 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 900 may receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector may receive the data carried in the infrared signal and appropriate circuitry may place the data on bus 902. Bus 902 carries the data to main memory 906, from which processor 904 retrieves and executes the instructions. The instructions received by main memory 906 may optionally be stored on storage device 910 either before or after execution by processor 904.

[0124] Computer system 900 also includes a communication interface 918 coupled to bus 902. Communication interface 918 provides a two-way data communication coupling to a network link 920 that is connected to local network 722. For example, communication interface 918 may be coupled to an integrated services digital network (ISDN) The communication interface 918 may be an ISDN (Instrumental Services Digital Network) card, cable modem, satellite modem, or modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 918 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. A wireless link may also be implemented. In any such implementation, communication interface 918 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0125] Network link 920 typically provides data communication through one or more networks to other data devices. For example, network link 920 may provide data communication through local network 922 to a host computer 924 or to a data center operated by an Internet Service Provider (ISP) 926. ISP 926 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the "Internet" 928. Local network 922 and Internet 928 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and network link 92 through communication interface 918 The signals on 0, which carry the digital data to and from computer system 900, are exemplary forms of transmission media.

[0126] Computer system 900 may send messages and receive data, including program code, through the network(s), network link 920 and communication interface 918. In the Internet example, a server 930 might transmit a requested code for an application program through Internet 928, ISP 926, local network 922 and communication interface 918.

[0127] The received code may be executed by processor 904 as it is received, and / or stored in storage device 910, or other non-volatile storage for later execution.

[0128] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary depending on the implementation. Accordingly, the specification and accompanying drawings should be considered in an illustrative rather than a restrictive sense. The sole and exclusive indication of the scope of the invention, and what is intended by the applicant to be the scope of the invention, is the literal and equivalent scope of the set of claims issuing from this application in the specific form in which such claims arise, including any subsequent amendments.< / identifier> < / object> < / object> < / object>

Claims

1. 1. A computer program storing instructions that, when executed by one or more processors, cause the computer to perform the following operations: accessing, by a client application, a configuration graph stored in a data store, the configuration graph indicating relationships between a first entity and a related second entity, the first entity being associated with a first object type; receiving, by a client application, from the data store a first object type definition corresponding to the first object type, the first object type definition defining a first set of data fields for the first object type, and the following operations further include: generating, by the client application, a first object of the first object type based on the first object type definition; receiving, by the client application, an update of the first object type definition from the data store, the update including a second object type definition, the second object type definition defining a second set of data fields different from the first set of data fields, and the following operations further comprising: generating, by the client application, a second object of a second object type based on (a) the second object type definition and (b) the first object of the first object type.

2. Creating the second object includes: identifying a particular field in the second set of data fields of the second object that does not correspond to any field in the first set of data fields; identifying a value for the particular field of the second set of data fields of the second object; and storing the value in association with the particular field of the second set of data fields of the second object.

3. The computer program product of claim 1 , wherein the first object and the second object are used to control functionality of the client application.

4. The second object type definition comprises: at least one first data field of the second set of data fields that is modifiable by the client application; and designating at least one second data field of the second set of data fields that may not be changed by the client application.

5. The instructions further include: and causing the client application to receive from the data store metadata including a first metadata module defining a first subtype of the second object type, the first subtype of the second object type including a first subset of data fields of the second set of data fields, the instructions further comprising: creating, by the client application, a third object of the first subtype; and fetching, by the client application, data values ​​for the first subset of data fields from the data store.

6. The instructions further include: receiving, by the client application, a request for a value of a particular data field that is not within the first subset of data fields; and searching, by the client application, the metadata to identify a second metadata module defining a second subtype of the second object type, the second subtype including the particular data field, the instructions further comprising: creating, by the client application, a fourth object of the second subtype; and fetching, by the client application, a data value for the fourth object from the data store.

7. The instructions further include: receiving a request by the client application to create a new field in the second object; based on determining that the new field (a) is not found in any object type stored in the data store, and (b) is not defined by the metadata maintained by the client application; updating, with the data store, the second object type to include the new field; and updating, by the client application, the metadata to include the new field.

8. 1. A method comprising: accessing, by a client application, a configuration graph stored in a data store, the configuration graph indicating relationships between a first entity and a related second entity, the first entity being associated with a first object type; receiving, by a client application, from a data store a first object type definition corresponding to a first object type, the first object type definition defining a first set of data fields for the first object type; generating, by the client application, a first object of the first object type based on the first object type definition; receiving, by the client application, an update of the first object type definition from the data store, the update including a second object type definition, the second object type definition defining a second set of data fields different from the first set of data fields, the method further comprising: generating, by the client application, a second object of a second object type based on (a) the second object type definition and (b) the first object of the first object type.

9. Creating the second object includes: identifying a particular field in the second set of data fields of the second object that does not correspond to any field in the first set of data fields; identifying a value for the particular field of the second set of data fields of the second object; and storing the value in association with the particular field of the second set of data fields of the second object.

10. The method of claim 8 , wherein the first object and the second object are used to control functionality of the client application.

11. The second object type definition comprises: at least one first data field of the second set of data fields that can be modified by the client application; and and designating at least one second data field of the second set of data fields that may not be changed by the client application.

12. receiving, by the client application, metadata from the data store, the metadata including a first metadata module defining a first subtype of the second object type, the first subtype of the second object type including a first subset of data fields of the second set of data fields; creating, by the client application, a third object of the first subtype; fetching, by the client application, data values ​​for a first subset of the data fields from the data store.

13. receiving, by the client application, a request for a value of a particular data field that is not within the first subset of data fields; searching, by the client application, the metadata to identify a second metadata module defining a second subtype of the second object type, the second subtype including the particular data field; and creating, by the client application, a fourth object of the second subtype; and fetching, by the client application, a data value for the fourth object from the data store.

14. receiving, by the client application, a request to create a new field in the second object; based on determining that the new field (a) is not found in any object type stored in the data store and (b) is not defined by the metadata maintained by the client application; updating, with the data store, the second object type to include the new field; and updating, by the client application, the metadata to include the new field.

15. 1. A system comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the system to: and causing a client application to access a configuration graph stored in a data store, the configuration graph indicating a relationship between a first entity and a related second entity, the first entity being associated with a first object type; and the instructions causing the one or more processors to: receiving, by a client application, from a data store a first object type definition corresponding to a first object type, the first object type definition defining a first set of data fields for the first object type, the instructions further comprising: generating, by the client application, a first object of the first object type based on the first object type definition; receiving, by the client application, an update of the first object type definition from the data store, the update including a second object type definition, the second object type definition defining a second set of data fields different from the first set of data fields, the instructions further comprising: and causing the client application to generate a second object of a second object type based on (a) the second object type definition and (b) the first object of the first object type.

16. Creating the second object includes: identifying a particular field in the second set of data fields of the second object that does not correspond to any field in the first set of data fields; identifying a value for the particular field of the second set of data fields of the second object; and storing the value in association with the particular field of the second set of data fields of the second object.

17. A memory storing the program according to any one of claims 1 to 7; and one or more processors for executing said program.

Images