Native application using database role

Abstract

The present disclosure relates to native applications using database roles. Embodiments of the present disclosure enable users of a data sharing system to build native applications that can be shared with other users of the data sharing system. Native applications can be published and discovered in the data sharing system like any other data list, and consumers can install them in their local data sharing system accounts to meet their data processing needs. Providers can define installation scripts for installing the applications, and create shared objects to which the installation scripts can be attached. In response to creating an imported database in a consumer account based on the shared object, the native application framework can automatically execute the installation scripts in the consumer account, and can create a set of database roles to manage execution of the application in the consumer account.

Description

[0001] Cross-references to related applications This application claims priority to co-pending U.S. Provisional Application No. 63 / 273,814, entitled “Native Applications Using DatabaseRoles,” filed October 29, 2021, which is incorporated herein by reference. Technical Field

[0002] This disclosure relates to data sharing platforms, and more particularly to shared applications within data sharing platforms. background Databases are widely used for data storage and access in computing applications. A database may include one or more tables that contain or reference data that can be read, modified, or deleted using queries. Databases can be used to store and / or access personal information or other sensitive information. Secure storage and access to database data can be provided by encrypting and / or storing data in encrypted form to prevent unauthorized access. In some cases, data sharing may be necessary to allow other parties to perform queries against a set of data. Brief description of the attached diagram The described embodiments and their advantages can be best understood by referring to the following description taken in conjunction with the accompanying drawings. These drawings are in no way intended to limit any changes in form and detail that may be made to the described embodiments by those skilled in the art without departing from the spirit and scope of the described embodiments.

[0003] Figure 1A This is a block diagram depicting an example computing environment in which the methods disclosed herein can be implemented, according to some embodiments of the present invention.

[0004] Figure 1B This is a block diagram of an example virtual warehouse according to some embodiments of the present invention.

[0005] Figure 2 This is a schematic block diagram of data that can be used to implement public or private data exchange according to some embodiments of the present invention.

[0006] Figure 3 This is a schematic block diagram illustrating the deployment of a data exchange according to some embodiments of the present invention, showing data access technologies managed by consumers and providers.

[0007] Figure 4 This is a block diagram illustrating the deployment of a data exchange according to some embodiments of the present invention, showing the application of sharing technology.

[0008] Figures 5A-5C For the purposes of this invention, some embodiments are described below. Figure 4 The diagram illustrates the code implementation of the application sharing technology described in the document.

[0009] Figure 6 The illustration illustrates the use of hidden roles to grant database roles to shared objects, according to some embodiments of the present invention.

[0010] Figure 7 This is a flowchart of a method for sharing applications among users in a data exchange according to some embodiments of the present invention.

[0011] Figure 8 This is a block diagram of an example computing device according to some embodiments of the present invention, which can perform one or more operations described herein. Detailed description Data providers often possess data assets that are difficult to share. These data assets can be data that another entity might be interested in. For example, a large online retailer might have a dataset containing the purchasing habits of millions of consumers over the past decade. This dataset can be enormous. If the online retailer wants to share all or part of this data with another entity, it might need to use outdated and slow methods to transfer the data, such as File Transfer Protocol (FTP), or even copy the data onto physical media and then mail the physical media to the other entity. This has several drawbacks. First, it's slow, as copying terabytes or petabytes of data can take days. Second, once the data is transferred, the provider has no control over what happens to it. The recipient can alter the data, make copies, or share it with other parties. Third, the only entities interested in accessing such large datasets in this way are large companies that can afford the complex logistics of transferring and processing the data, as well as the high cost of such cumbersome data transfers. Therefore, smaller entities (e.g., "mom-and-pop stores") or even smaller, more agile, cloud-centric startups often cannot access this data because it is too expensive, even if the data could be valuable to their business. This is likely because raw data assets are often too coarse, riddled with potentially sensitive data, to be simply sold or provided directly to other companies. Data owners must first perform data cleaning, de-identification, aggregation, concatenation, and other forms of data enrichment before sharing with another party. This is both time-consuming and expensive. Finally, for the reasons mentioned above, traditional data sharing methods do not allow for scalable sharing, making it difficult to share data assets with many entities. Traditional sharing methods also introduce latency and delays to all parties accessing the most recently updated data.

[0012] Private and public data exchanges enable data providers to more easily and securely share their data assets with other entities. Public data exchanges (also referred to herein as the "Snowflake datamarketplace" or "data marketplace") provide a centralized repository with open access, where data providers can publish and control live and read-only datasets to thousands of consumers. Private data exchanges (also referred to herein as "data exchanges") can operate under the brand of a data provider, who can control who has access to the data. Data exchanges can be for internal use only or open to consumers, partners, vendors, or others. Data providers can control which data assets are listed and who has access to which datasets. This allows for a seamless way to discover and share data within the data provider's organization and with its business partners.

[0013] It can be achieved through cloud computing services, such as SNOWFLAKE. TM Cloud computing services facilitate data exchange and allow data providers to offer data assets directly from their own online domains (such as websites) within their own branded private online marketplaces. Data exchange marketplaces provide entities with a centralized, managed hub to list internally or externally shared data assets, foster data collaboration, and maintain data governance and audit access. Through data exchange marketplaces, data providers can share data between companies without duplicating it. Data providers can invite other entities to view their data listings, control which data listings appear in their private online marketplaces, control who can access the data listings, and how others can interact with the data assets connected to those listings. This can be viewed as a “walled garden” marketplace where visitors must be approved to enter, and access to certain listings may be restricted.

[0014] For example, Company A could be a consumer data company that has collected and analyzed the consumption habits of millions of individuals across several different categories. Their datasets could include data on categories such as online shopping, video streaming, electricity consumption, car use, internet use, clothing purchases, mobile app purchases, club memberships, and online subscription services. Company A might want to offer these datasets (or subsets or derivatives of these datasets) to other entities. For example, a new clothing brand might want access to datasets related to consumer clothing purchases and online shopping habits. Company A could support a page on its website that is, or functions essentially, a data exchange, where data consumers (e.g., the new clothing brand) can directly browse, explore, discover, access, and potentially purchase datasets from Company A. Furthermore, Company A can control: who can access the data exchange, which entities can view specific lists, the actions entities can take on the lists (e.g., view only), and any other appropriate actions. Additionally, data providers can combine their own data with other datasets from, for example, public data exchanges (also known as “data marketplaces”) and use the combined data to create new lists.

[0015] Data exchanges can be suitable venues for discovering, aggregating, cleaning, and enriching data to make it more valuable. A large company on a data exchange can aggregate data from its various branches and departments that may be valuable to another company. Furthermore, participants in private ecosystem data exchanges can work together to connect their datasets and collaboratively create useful data products that none of them could produce alone. Once these related datasets are created, they can be listed on data exchanges or data marketplaces.

[0016] Shared data can be executed when a data provider creates a shared object (hereinafter referred to as a "share") of a database in its account and grants shared access to specific objects of the database (e.g., tables, secure views, and secure user-defined functions (UDFs)). A read-only database can then be created using the information provided in the share. Access to the database can be controlled by the data provider. A "share" encapsulates all the information required to share data in the database. A share may include at least three pieces of information: (1) privileges to access the database and schema containing the objects to be shared, (2) privileges to access specific objects (e.g., tables, secure views, and secure UDFs), and (3) the consumer accounts that share the database and its objects. The consumer accounts that share the database and its objects may be indicated by a list of references to those consumer accounts contained within the shared object. Only those consumer accounts specifically listed in the shared object may be allowed to look up, access, and / or import from the shared object. By modifying the reference lists of other consumer accounts, a shared object can be accessed by more accounts or restricted to fewer accounts.

[0017] In some embodiments, each shared object contains a single role. The authorization between this role and the object defines which objects are shared and which privileges these objects share. Roles and authorizations can be similar to any other role and authorization system in a role-based access control implementation. By modifying the set of authorizations attached to a role in the shared object, more objects can be shared (by adding authorizations to the role), fewer objects can be shared (by revoking authorizations for the role), or objects can be shared with different privileges (by changing the authorization type, for example, to allow write access to previously read-only shared table objects). In some embodiments, shared objects in a provider account can be imported into a target consumer account using alias objects and cross-account role authorizations.

[0018] When sharing data, data is not copied or transferred between users. This is achieved through methods such as SNOWFLAKE. TM The data is shared using cloud computing services provided by a cloud service provider. The shared data can then be used to process SQL queries, which may include joins, aggregations, or other analyses. In some cases, the data provider can define a share that allows "secure connections" to be performed on the shared data. Secure connections can be performed to enable analytics on the shared data, but the actual shared data cannot be accessed by the data consumer (e.g., the recipient of the share).

[0019] The data exchange can also implement role-based access control to manage access to objects within a consumer account using account-level roles and authorizations. In one embodiment, an account-level role is a special object assigned to a user within a consumer account. The authorizations between these account-level roles and database objects define what privileges the account-level roles have over those objects. For example, a role with use authorization over a database can "see" the database when executing the command "show database"; a role with select authorization over a table can read from the table but cannot write to it. A role needs modification authorization over the table to write to it.

[0020] Consumers of data typically require the ability to perform various functions on the data they share. This often involves consumers sharing data with one or more third parties, having these third parties run services on the data, and sending the results back to the consumer. In addition to the delays caused by relying on third-party services, consumers also need to share potentially sensitive data with these third parties.

[0021] The embodiments of this disclosure address the aforementioned and other problems by enabling users of the data marketplace to build native applications that can be shared with other users in the data marketplace. Native applications can be published and discovered in the data marketplace like any other data listing, and consumers can install them in their local data marketplace accounts to meet their data processing needs. This facilitates bringing data processing services and capabilities to consumers, rather than requiring them to share data with, for example, service providers who can perform these data processing services and share the processed data back to the consumer. In other words, instead of requiring consumers to share potentially sensitive data with a third party capable of performing the necessary data processing services and sending the results back to the consumer, the desired data processing functionality can be encapsulated and then shared with the consumer, so that the consumer does not have to share their potentially sensitive data. The embodiments of this disclosure also protect providers who may not want the underlying details of their applications (e.g., source code) to be shared.

[0022] Figure 1A This is a block diagram of an example computing environment 100 in which the systems and methods disclosed herein can be implemented. Specifically, a cloud computing platform 110, such as Amazon Web Services, can be implemented. TM (AWS), MICROSOFT AZURE TM Google Cloud 110 provides computing and storage resources that can be acquired (purchased) or leased and configured to perform applications and store data, as is known in the art.

[0023] Cloud computing platform 110 can host cloud computing service 112, which facilitates data storage (e.g., data management and access), analysis functions (e.g., SQL queries and analysis), and other computing capabilities (e.g., secure data sharing among users of cloud computing platform 110) on cloud computing platform 110. Cloud computing platform 110 may include a three-tier architecture: data storage 140, query processing 130, and cloud services 120.

[0024] Data storage 140 can facilitate storing data in one or more cloud databases 141 on cloud computing platform 110. Data storage 140 can use technologies such as Amazon S3. TM The storage service stores data and query results on the cloud computing platform 110. In a particular embodiment, to load data into the cloud computing platform 110, data tables can be horizontally partitioned into large, immutable files, which can resemble blocks or pages in a traditional database system. Within each file, the values ​​of each attribute or column are grouped together and compressed using a scheme sometimes referred to as a hybrid columnar approach. Each table has a header that contains offsets for each column within the file, in addition to other metadata.

[0025] In addition to storing table data, data storage 140 also helps store temporary data generated by query operations (such as joins) and data contained in the results of large queries. This allows the system to compute large queries without encountering out-of-memory or out-of-disk errors. Storing query results in this way simplifies query processing because it eliminates the need for server-side cursors found in traditional database systems.

[0026] Query processing 130 can handle query execution within an elastic cluster of virtual machines (referred to herein as a virtual warehouse or data warehouse). Therefore, query processing 130 can include one or more virtual warehouses 131, which may also be referred to herein as data warehouses. Virtual warehouse 131 can be one or more virtual machines running on cloud computing platform 110. Virtual warehouse 131 can be computing resources that can be created, destroyed, or resized at any time as needed. This functionality can create “elastic” virtual warehouses that can be expanded, shrunk, or shut down according to user needs. Expanding a virtual warehouse involves creating one or more compute nodes 132 to virtual warehouse 131. Shrinking a virtual warehouse involves removing one or more compute nodes 132 from virtual warehouse 131. More compute nodes 132 can result in faster computation times. For example, data loading that takes 15 hours on a system with four nodes may only take 2 hours on a system with 32 nodes.

[0027] Cloud service 120 may be a collection of services that coordinate activities on cloud computing service 112. These services bundle together all the different components of cloud computing service 112 to handle user requests from login to query distribution. Cloud service 120 can operate on computing instances provided by cloud computing service 112 from cloud computing platform 110. Cloud service 120 may include services that manage virtual repositories, queries, transactions, data exchange, and a collection of metadata associated with these services, such as database schemas, access control information, encryption keys, and usage statistics. Cloud service 120 may include, but is not limited to, authentication engine 121, infrastructure manager 122, optimizer 123, exchange manager 124, security engine 125, and metadata storage device 126.

[0028] Figure 1B This is a block diagram illustrating an example virtual warehouse 131. Exchange manager 124 can use, for example, a data exchange to facilitate data sharing between data providers and data consumers. For example, cloud computing service 112 can manage the storage and access to database 108. Database 108 may include various instances of user data 150 for different users (e.g., different enterprises or individuals). User data 150 may include a user database 152 containing data stored and accessed by that user. User database 152 may be subject to access controls, such that only the data owner is allowed to change and access database 152 after authentication with cloud computing service 112. For example, data may be encrypted such that it can only be decrypted using decryption information possessed by the data owner. Using exchange manager 124, specific data from user database 152 subject to these access controls can be shared with other users in a controlled manner according to the methods disclosed herein. In particular, users can specify share 154, which, as described above, can be shared in an uncontrolled manner in a public or data exchange, or shared in a controlled manner with specific other users. The term "share" encapsulates all the information required for sharing data in the database. Sharing may include at least three pieces of information: (1) privileged access to the database and schema containing the objects to be shared, (2) privileged access to specific objects (e.g., tables, security views, and security UDFs), and (3) the consumer account with which the database and its objects are shared. Data is not copied or transferred between users when sharing data. Sharing is accomplished through cloud service 120 of cloud computing service 112.

[0029] Shared data can be executed when a data provider creates a database share in their account and grants access to specific objects (such as tables, secure views, and secure user-defined functions (UDFs)). A read-only database can then be created using the information provided in the share. Access to that database can be controlled by the data provider.

[0030] The shared data can then be used to process SQL queries, which may include joins, aggregations, or other analyses. In some cases, the data provider can define a share that allows "secure connections" to be performed on the shared data. Secure connections can be performed to enable analysis to be performed on the shared data, but the actual shared data cannot be accessed by the data consumer (e.g., the recipient of the share). Secure connections can be performed as described in U.S. Application Serial No. 16 / 368,339, filed March 18, 2019.

[0031] User devices 101-104, such as laptop computers, desktop computers, mobile phones, tablet computers, cloud-hosted computers, cloud-hosted serverless processes, or other computing processes or devices, can be used to access virtual warehouses 131 or cloud services 120 via networks 105 such as the Internet or private networks.

[0032] In the following description, actions are attributed to users, particularly consumers and providers. It should be understood that such actions pertain to devices 101-104 operated by such users. For example, a notification to a user can be understood as a notification sent to device 101-104, input or instructions from a user can be understood as being received through the user's device 101-104, and user interaction with an interface should be understood as interaction with an interface on the user's device 101-104. Furthermore, database operations (connections, aggregations, analyses, etc.) attributed to a user (consumer or provider) should be understood to include cloud computing service 112 performing such actions in response to instructions from that user.

[0033] Figure 2 This is a schematic block diagram of data that can be used to implement public or data exchange according to embodiments of the present invention. Exchange manager 124 can operate with respect to some or all of the exchange data 200 shown, which may be stored on the platform executing exchange manager 124 (e.g., cloud computing platform 110) or elsewhere. Exchange data 200 may include multiple lists 202 describing data shared by a first user (“Provider”). Lists 202 may be lists in a data exchange or a data marketplace. For both data marketplaces and data exchanges, access control, management, and governance of the lists may be similar.

[0034] List 202 may include metadata 204 describing the shared data. Metadata 204 may include some or all of the following information: the identifier of the provider of the shared data, the URL associated with the provider, the name of the share, the name of the table, the category to which the shared data belongs, the update frequency of the shared data, the table's directory, the number of columns and rows in each table, and the column names. Metadata 204 may also include examples to help users use the data. Such examples may include sample tables (which include samples of rows and columns of sample tables), sample queries that can be run against the table, sample views of the sample table, and sample visualizations based on the table data (e.g., charts, dashboards). Other information included in metadata 204 may be metadata for use by business intelligence tools, textual descriptions of the data contained in the table, keywords associated with the table to facilitate searches, links to documents related to the shared data (e.g., URLs), and refresh intervals indicating the update frequency of the shared data and the last update date of the data.

[0035] List 202 may include access control 206, which can be configured with any suitable access configuration. For example, access control 206 may indicate that shared data is unrestrictedly available to any member for private exchange (as used elsewhere in this document, "any share"). Access control 206 may specify user categories (members of a specific group or organization) who are allowed to access the data and / or view the list. Access control 206 may specify "peer-to-peer" sharing (see [link to documentation]). Figure 4 (as discussed in the document), where a user can request access, but is only permitted with the provider's approval. Access control 206 can specify a set of user identifiers that are excluded from accessing the data referenced in list 202.

[0036] Note that some list 202 errors may be discovered by users without further authentication or access permission, and actual access is only granted after subsequent authentication steps (see [link to relevant documentation]). Figure 4 and Figure 6 (Discussion). Access control 206 can specify that list 202 can only be discovered by specific users or specific categories of users.

[0037] It should also be noted that the default behavior of List 202 is that the data referenced by the shared data cannot be exported by consumers. Optionally, Access Control 206 can specify that this is not allowed. For example, Access Control 206 can specify that security operations (such as secure connections and security functions, discussed below) can be performed on the shared data, making it impossible to view and export the shared data.

[0038] In some embodiments, once a user is authenticated with respect to list 202, a reference to that user (e.g., the user identifier of the user's account in virtual repository 131) is added to access control 206, so that the user can subsequently access the data referenced by list 202 without further authentication.

[0039] List 202 can define one or more filters 208. For example, filter 208 can define a specific user identifier 214 for users who can view references to list 202 when browsing directory 220. Filter 208 can define user categories (users in a specific industry, users associated with a specific company or organization, users within a specific geographic region or country) that can view references to list 202 when browsing directory 220. In this way, private exchanges can be implemented by exchange manager 124 using the same components. In some embodiments, excluded users in excluded access list 202 (i.e., those added to the consumption share 116 of excluded users) can still be allowed to view a representation of the list when browsing directory 220 and can be further allowed to request access to list 202, as described below. Requests for access to the list by such excluded users and other users can be listed in the interface presented to the provider of list 202. The provider of list 202 can then view the access requests and select extended filter 208 to grant access rights to excluded users or categories of excluded users (e.g., users in excluded geographic regions or countries).

[0040] Filter 208 can further define which data a user can view. Specifically, filter 208 can instruct that a user who selects list 202 to add to a user's consumption share 116 is allowed access to only a filtered version of the data referenced by that list, which includes only data associated with the user's identifier 214, associated with the user's organization, or specific to a particular category of the user. In some embodiments, private exchanges are conducted by invitation: after accepting an invitation received from the provider, a user invited by the provider to view list 202 of private exchanges is allowed to conduct private exchanges through exchange manager 124.

[0041] In some embodiments, list 202 can be addressed to a single user. Therefore, a reference to list 202 can be added to a set of "pending shares" that the user can view. Then, after the user passes approval to exchange manager 124, list 202 can be added to the user's set of shares.

[0042] List 202 may further include usage data 210. For example, cloud computing service 112 may implement a points system where points are purchased by users and consumed each time a user runs a query, stores data, or uses other services implemented by cloud computing service 112. Therefore, usage data 210 may record points consumed by accessing shared data. Usage data 210 may include other data such as the number of queries, the number of aggregations of each of several types performed on the shared data, or other usage statistics. In some embodiments, user usage data for list 202 or multiple lists 202 is provided to the user in the form of a shared database, i.e., references to the database including the usage data are added to the user's consumption share 116 by exchange manager 124.

[0043] List 202 may also include a heat map 211, which may represent the geographic location clicked by a user on that particular list. Cloud computing service 112 may use the heat map to make replication decisions or other decisions about the list. For example, a data exchange may display a list containing weather data for the state of Georgia, USA. Heat map 211 may indicate that many users in California are selecting the list to check the weather in Georgia. Given this information, cloud computing service 112 may replicate the list and make it available in a database (the server of which is physically located in the western United States), making the data accessible to consumers in California. In some embodiments, an entity may store its data on a server located in the western United States. A particular list may be very popular with consumers. Cloud computing service 112 may replicate the data and store it on a server located in the eastern United States, making the data accessible to consumers in the Midwest and East Coast as well.

[0044] List 202 may also include one or more tags 213. Tags 213 can facilitate simpler sharing of data contained in one or more lists. For example, a large company may have a Human Resources (HR) list containing HR data for its internal employees in a data exchange. HR data may contain ten types of HR data (e.g., employee number, chosen health insurance, current retirement plan, job title, etc.). 100 people in the company (e.g., everyone in the HR department) can access the HR list. HR management may want to add an eleventh type of HR data (e.g., employee stock option plans). Instead of manually adding it to the HR list and granting access to the new data to each of the 100 people, management can simply apply an HR tag to the new dataset, and this HR tag can be used to categorize the data as HR data, list it along with the HR list, and grant the 100 people access to view the new dataset.

[0045] List 202 may also include version metadata 215. Version metadata 215 provides a way to track how the dataset changes. This helps ensure that data being viewed by an entity is not prematurely changed. For example, if a company owns the original dataset and then releases an updated version of that dataset, the update might interfere with another user's processing of the dataset because the update might have a different format, new columns, and other changes that may be incompatible with the recipient user's current processing mechanisms. To remedy this, cloud computing service 112 can use version metadata 215 to track version updates. Cloud computing service 112 can ensure that each data consumer accesses the same version of the data until they accept an updated version that does not interfere with the current processing of the dataset.

[0046] The exchange data 200 may further include user record 212. User record 212 may include data that identifies the user associated with user record 212, such as an identifier (e.g., a repository identifier) ​​of a user who has user data 151 in service database 128 and is managed by virtual repository 131.

[0047] User record 212 may list shares associated with a user, such as a reference list 202 created by the user. User record 212 may also list shares consumed by the user, such as a reference list 202 created by another user and associated with the user's account according to the methods described herein. For example, list 202 may have an identifier that will be used to reference it in the shared or consumed share 116 of user record 212.

[0048] The exchange data 200 may further include a directory 220. Directory 220 may include a list of all available lists 202 and may include an index of data from metadata 204 to facilitate browsing and searching according to the methods described herein. In some embodiments, lists 202 are stored in the directory as JavaScript Object Notation (JSON) objects.

[0049] Note that in the case of multiple instances of Virtual Repository 131 existing on different cloud computing platforms, the directory 220 of one instance of Virtual Repository 131 may store lists or references to lists from other instances on one or more other cloud computing platforms 110. Therefore, each list 202 can be globally unique (e.g., all instances across Virtual Repository 131 are assigned globally unique identifiers). For example, instances of Virtual Repository 131 may synchronize copies of their directory 220 such that each copy indicates a list 202 available from all instances of Virtual Repository 131. In some instances, the provider of list 202 may specify that it will only be available on one or more specified computing platforms 110.

[0050] In some embodiments, directory 220 is available on the Internet, making it searchable by search engines such as Bing or Google. The directory may be subject to search engine optimization (SEO) algorithms to improve its visibility. Potential consumers can therefore browse directory 220 from any web browser. Exchange manager 124 may publicly link to a Uniform Resource Locator (URL) for each listing 202. This URL may be searchable and can be shared outside of any interface implemented by exchange manager 124. For example, the provider of listing 202 may publish the URL of their listing 202 to promote the use of their listing 202 and its brand.

[0051] Figure 3 The diagram illustrates a cloud environment 300 including a cloud deployment 305, which may include cloud computing services 112 (in... Figure 1A A similar architecture is shown in the diagram, and it can be a deployment of a data exchange or a data marketplace. Although illustrated as a single cloud deployment, cloud environment 300 can have multiple cloud deployments, which may be physically located in separate, remote geographical areas, but can all be deployments of a single data exchange or data marketplace. Although embodiments of this disclosure are described with respect to data exchanges, this is for illustrative purposes only, and embodiments of this disclosure can be implemented in any suitable enterprise database system or data sharing platform, where data can be shared among users of the system / platform.

[0052] Cloud deployment 305 may include hardware such as processing devices 305A (e.g., processors, central processing units (CPUs)), memory 305B (e.g., random access memory (RAM), storage devices (e.g., hard disk drives (HDDs), solid-state drives (SSDs)), and other hardware devices (e.g., sound cards, graphics cards, etc.). Storage devices may include permanent storage devices capable of storing data. Permanent storage devices may be local or remote storage units. Permanent storage devices may be magnetic storage units, optical storage units, solid-state storage units, electronic storage units (main memory), or similar storage units. Permanent storage devices may also be a single chip / device or a group of distributed devices. Cloud deployment 305 may include any suitable type of computing device or machine with a programmable processor, including, for example, server computers, desktop computers, laptop computers, tablet computers, smartphones, set-top boxes, etc. In some examples, cloud deployment 305 may include a single machine or may include multiple interconnected machines (e.g., multiple servers configured in a cluster).

[0053] Databases and schemas are used to organize data stored in a cloud deployment 305. Each database can belong to a single account within the cloud deployment 305. Each database can be thought of as a container with a classic folder hierarchy. Each database can be a logical grouping of schemas, and schemas can be logical groups of database objects (tables, views, etc.). Each schema can belong to a single database. Databases and schemas can together form a namespace. When any operation is performed on objects within a database, the namespace is inferred from the current database and the schema used for the session. If the database and schema are not used for a session, the namespace must be explicitly specified when performing any operation on objects. Figure 3 As shown, cloud deployment 305 may include provider account 310, which includes database DB1 with modes 320A-320D.

[0054] Figure 3 Shared access to objects in provider account 310 is also illustrated. Provider account 310 can create shared object 315, which includes authorizations for database DB1 and schema 320A, as well as authorizations for table T2 located in schema 320A. The authorizations on database DB1 and schema 320A can be use authorizations, while the authorizations on table T2 can be opt-in authorizations. In this case, table T2 in schema 320A in database DB1 will be shared as read-only. Shared object 315 may contain a list of references to various consumer accounts (not shown), including consumer account 350.

[0055] Once shared object 315 is created, it can be imported or referenced by consumer account 350 (which is already listed in shared object 315). Consumer account 350 can run commands to list all shared objects available for import. Consumer account 350 only uses the command to list all shared objects to display the shared object and subsequently imports it if shared object 315 was created through a reference to consumer account 350. In one embodiment, a reference to a shared object in another account is always qualified by account name. For example, consumer account 350 would reference shared object SH1 in provider account A1 with the example qualified name “A1.SH1”. When shared object 315 is imported into consumer account 350 (shown as imported database 355), the administrator role (e.g., account-level role) of consumer account 350 can be granted authorization to use the imported database 355. In this way, a user in account 350 with an administrator role can access data from DB1 that is explicitly shared / included in shared object 315.

[0056] Figure 3 Database role 360 ​​is also shown. Besides database roles, which can exist within a database (e.g., ... Figure 3 In addition to the fact that it is defined within DB1 (as in the example) or any suitable database container (e.g., schema), a database role can function similarly to an account-level role. Database role 360 ​​can be an object different from an account-level role or any other object type (e.g., it could be a new object type) and can be referenced using a qualifier based on the name of the database in which it is created (e.g., DB1.ROLE1). Although database role 360 ​​can resemble an account-level role in terms of the privileges that can be granted, database role 360 ​​can exist exclusively within database DB1 (the database in which it is defined). Therefore, the privileges granted to database role 360 ​​must be limited in scope to the objects contained within database DB1 in which database role 360 ​​is defined. Database role 360 ​​can allow the privileges provided by shared object 315 to be modularized to provide access only to certain objects authorized by shared object 315 in database DB1.

[0057] When replicating a database, the corresponding account-level roles can be replicated, or the database itself can be designated as a replication unit. By defining database role 360 ​​within database DB1, explicit separation can be achieved between database role 360 ​​and other replication units (e.g., account-level roles). Because privileges are granted to database role 360 ​​on a subset of objects within database DB1 (which has no other databases), database role 360 ​​and the subset of objects on which it is granted privileges (e.g., modular privileges) are maintained within database DB1. Furthermore, the execution role of provider account 310 must have use privileges on database DB1, in which database role 360 ​​is defined, in order to resolve it.

[0058] In this way, if provider account 310 grants a consumer account access to shared objects that have been granted privileges to database DB1, the consumer account can see all the contents of DB1. However, by utilizing multiple database roles, each granted privileges to specific objects (e.g., a subset of objects) within database DB1, a consumer account can only see / access objects for which privileges have been granted by the database role, even if the consumer account has already been granted access to that database role. Database roles can be granted to account-level roles or other database roles within the same database. Database roles cannot be granted to another database role in a different database.

[0059] In some cases, a provider account can grant database roles to multiple shared objects, and a consumer account can import each of these shared objects to generate multiple imported databases in the consumer account. The consumer account can then grant the same account-level role to the imported database role in each imported database. However, in this scenario, different database objects must be granted to each shared object in separate authorizations; otherwise, a single revocation operation on a given shared object / imported database would result in the revocation of all authorizations for the database role. To prevent this, embodiments of this disclosure utilize a concept known as hidden roles when granting database roles to shared objects. Figure 6 This is a diagram of deployment 600, illustrating the use of hidden roles to grant database roles to one or more shared objects. (Example) Figure 6 As shown, when a provider account wishes to grant a database role (DB1.ROLE1) to shared object 605, it can create a new hidden role 605A. Hidden role 605A can be a database role or an account-level role, and can be anonymous (i.e., without a name). DB1.ROLE1 can be granted to hidden role 605A, and hidden role 605A can be granted to shared object 605. DB1.ROLE1 can be granted to each of shared objects 605, 606, and 607 in this way to establish a one-to-one relationship between database roles and shared objects. By doing so, revoking DB1.ROLE1 from, for example, shared object 605 will not affect the granting of DB1.ROLE1 to shared objects 606 or 607. Once DB1.ROLE1 is granted to each of shared objects 605-607 in this way, a consumer account can import each of shared objects 605-607 and generate shared databases 610-612 based on each of shared objects 605-607 respectively. Furthermore, the use of hidden objects ensures that authorizations granted only through that shared object are discarded when a shared object is deleted or an account is removed from it. In short, whenever a database role is granted to a shared object, a hidden role is created for both the granted database role and the shared object (i.e., the shared authorized party).

[0060] In some embodiments, any object granted to a shared object by a provider account does not result in the automatic creation of that object in the consumer account. This avoids lifecycle issues. For example, if a shared database role is renamed, it is not necessary to rename all existing automatically created objects. In another example, if a database role is discarded, it is not necessary to discard all existing automatically created objects. In yet another example, if a new database role is added to a shared object in the provider account, objects granted privileges to the new database role will not be automatically created in all existing shared databases in the consumer account.

[0061] Similar to how data can be shared from provider accounts to consumer accounts, applications can also be shared from provider accounts to consumer accounts. Embodiments of this disclosure enable users of data marketplaces to build native applications that can be shared with other users in the data marketplace. Native applications can be published and discovered in the data marketplace like any other data list, and consumers can install them in their accounts to meet their needs (e.g., data processing needs). This facilitates bringing data processing services and capabilities to consumers, rather than requiring consumers to share data with service providers who can perform these data processing services and share the processed data back to the consumers. In other words, instead of entities having to share data with third parties, have those third parties run their services on them, and send the results back to the entities, the functionality of applications can be encapsulated and then shared with entities, so that entities do not have to share their potentially sensitive data.

[0062] Similar to data sharing, shared containers can be used to share native applications (hereinafter referred to as applications). Providers can define application shared objects (the same as standard shared objects) and can couple a database, including an installation script for installing the application, to the application shared object. In some embodiments, the installation script can be in the form of a stored procedure. Stored procedures can be similar to functions, as they are both evaluated as expressions. However, unlike functions, stored procedures are used via CALL statements and do not appear in other statement types (e.g., in the SELECT or WHERE part of a query). A key characteristic of stored procedures is their ability to execute other queries and access their results. Like functions, stored procedures can be created once and then executed multiple times. In fact, stored procedures implemented in, for example, JavaScript can be considered JavaScript UDFs, adding the ability to issue additional queries during the execution of the JavaScript body. When a consumer imports the database natively coupled to the application shared object, it triggers the execution of the installation script, which builds all the objects and procedures required for the application to run, as discussed in further detail here.

[0063] In some embodiments, there may be two types of stored procedures: owner-privileged and caller-privileged. Owner-privileged stored procedures (such as `example_sp`) can be defined in one context and invoked in another. A context can refer to the security and naming context in which a sub-job of the stored procedure executes. This context can include the account, role, and schema used to compile queries (i.e., for name resolution and authorization). For example, the stored procedure `example_sp` might be defined in account A1, owned by role R1, and located in schema S1 (database DB1); this combination of information is called the owner context. On the other hand, the invocation privileges of `example_sp` can be granted to any other role R2 in account A2 (possibly the same as A1). Role R2 can invoke `example_sp` from any default schema S2 (the default schema of the session) using a query like `CALL DB1.S1.example_sp();.` with repository WH (the default repository of the session). The combination of the caller's account, role, schema, and repository is called the caller context. In contrast to owner-privileged stored procedures, sub-jobs of caller-privileged stored procedures execute in the caller's context. Therefore, they are not specially handled; the default context of the caller session (i.e., schema, role, and account) is used for name resolution and authorization purposes. Thus, unlike owner permission types, the default repository can be changed during principal execution (via subjobs).

[0064] Figure 4 A cloud environment 300 according to some embodiments of this disclosure is illustrated. After creating database DB1 and schema 320A, provider account 310 can generate installation script 410 and store it as a stored procedure in schema 320A. Native application framework 475 enables provider account 310 to indicate that a specific stored procedure is an installation script, which will be automatically invoked without parameters when a consumer that has shared the stored procedure with it requests to install the application, as discussed in further detail herein.

[0065] Provider account 310 can define an installation script 410 with the necessary functionality to install the application (including any objects and procedures required by the application) in consumer account 350. Provider account 310 can create application shared object 430 in the same way as creating a regular shared object and attach the installation script 410 to application shared object 430. Provider account 310 can then grant application shared object 430 the necessary privileges, including use on database DB1, use on schema 320A, and use on installation script 410.

[0066] When consumer account 350 runs commands to view available shares, they can view application shared objects 430 and import application shared objects 430 to create an imported database 460 from them. In response to the creation of the imported database 460, the native application framework 475 can automatically trigger the execution of an installation script 410, which can create objects and tasks / procedures corresponding to the functions of the application in consumer account 350. For example, installation script 410 can create a process that periodically contacts a third-party API and retrieves data from the third-party API into the imported database 460 for processing. Because the application must access data and perform various functions, the imported database 460 is no longer a read-only database, as it includes not only application shared objects 430 from provider account 310 (read-only) but also objects created locally within the imported database via stored procedures / installation scripts 410 attached to the application.

[0067] The native application framework 475 can create a set of database roles as part of the application installation to assist in the sharing process. More specifically, the native application framework 475 can create a master database role 470, which can represent the application itself and control the execution of the installation script 410, as well as the use or execution of any objects or processes corresponding to the functionality of the application generated by the installation script 410. In other words, the master database role 470 can control the application, similar to a top-level role in an account. The master database role 470 enables the installation script 410 to execute in the context of the consumer account 350, but using a model of permissions similar to (but not the same as) those of the provider account 310. It should be noted that the master database role 470 does not execute using the permissions of the provider account 310 (the owner), because it is defined in the provider account 310, which has no privileges in the consumer account 350. It should also be noted that the master database role 470 does not execute using the (caller's) permissions of the consumer account 350, because the consumer account 350 may not want to absolutely trust the installation script 410 and does not want the stored procedure corresponding to the installation script 410 to inherit any privileges granted to the consumer account 350. In fact, the stored procedure executes within the context of the master database role 470 (i.e., the application's permissions).

[0068] The native application framework 475 can also create an exporter database role 480, to which the installation script 410 can grant licenses to certain objects and / or processes (corresponding to application functionality) created by it (the installation script 410) during application installation. The native application framework 475 can also create an importer database role 490. When objects / licenses of the consumer account 350 are granted to the application, the importer database role 490 can automatically acquire these objects / licenses. The native application framework 475 can automatically grant the importer database role 490 to the master database role 470, enabling the master database role 470 to assume responsibility for granting all licenses to the application (through the importer database role 490). The native application framework 475 can also automatically grant the exporter database role 480 to the administrator role 485 (i.e., the role through which the consumer account 350 installs the application), the administrator role 485 being an account-level role of the consumer account 350. As a result, certain objects and / or processes granted to the exporter database role 480 by the installation script 410 are visible / accessible to the consumer account 350 (e.g., accessible by the administrator role 485). For example, during the installation of objects and processes required for application operation, the installation script 410 may create schema S2 and table T2. The installation script 410 may be defined to grant the exporter database role 480 access to schema S2 and selective access to T2, thus giving it selective access to T2. By defining the basic functionality of the native application framework 475, the exporter database role 480 is granted the administrator role 485 (i.e., the role that executes the installation script). Therefore, the consumer account 350 (e.g., through the administrator role 485) can have selective access to table T2.

[0069] In this way, the master database role 470 can provide fine-grained access to objects of the application shared object 430 through the exporter database role 480 (as opposed to an all-or-nothing approach), as further detailed herein. Furthermore, different collections can be assigned to different roles on the consumer side. It should be noted that when the consumer account 350 installs the application, the installation script 410 itself is not granted the exporter database role 480, therefore the consumer account 350 cannot see or access it in any way. Similarly, any data created by the installation script 410 (e.g., objects, procedures, schemas, tables, etc.) is invisible / inaccessible to the consumer account 350 (e.g., any consumer role) by default unless the installation script 410 instructs them to be granted the exporter database role 480. However, if any object or procedure is not granted the exporter database role 480, then it is meant to be used solely by the application.

[0070] exist Figure 4In the example, provider account 310 can grant necessary privileges to application shared object 430 by granting access permissions to database DB1, mode 320A, and installation script 410 to the hidden role 450 of application shared object 430. Consumer account 350 (via administrator role 485) can create an imported database 460 from application shared object 430. In response, native application framework 475 can automatically trigger the execution of installation script 410 in consumer account 350. Because installation script 410 has been granted the hidden role 450, and the hidden role 450 is specifically granted the master database role 470, consumer account 350 cannot access installation script 410. More specifically, consumer account 350 cannot access the contents of installation script 410, cannot see the contents of installation script 410, and has no usage permissions for installation script 410. However, consumer account 350 can execute installation script 410 because the native application framework 475 automatically triggers the execution of installation script 410 within consumer account 350 once they import application shared objects 430, even though consumer account 350 cannot actually access the underlying contents of installation script 410. Furthermore, if application installation requires other data / objects (e.g., tables, etc.), provider account 310 can also specifically grant these objects to the master database role 470, and they will also be invisible / inaccessible to consumer account 350. In this way, by default, consumer account 350 does not have permission to view or execute any objects or processes created by installation script 410 during application installation. Unless installation script 410 instructs certain objects and / or processes created during application installation to be granted to exporter database role 480, consumer account 350 cannot view, access, or otherwise utilize them.

[0071] Therefore, embodiments of this disclosure also protect application providers who may not wish to share their application details (such as underlying code / logic) with consumers. In fact, a provider account may want a consumer account to be able to execute the application, but may not want the consumer account to be able to access the application's content.

[0072] Consumer account 350 can create necessary objects that will be used by the application, such as credentials, API integrations, and repositories. Consumer account 350 can also grant privileges necessary for the application to run (some privileges are granted to objects managed and owned by consumer account 350), including the use of secrets, the use of API integrations, the use of repositories, and privileges granted to the data application if it needs to access objects in consumer account 350 or execute procedures within consumer account 350. Once installed, the application can perform various functions within consumer account 350 as long as it has been authorized. The application can act as a proxy and take any action that any role on consumer account 350 can take, such as establishing task pipelines, establishing data ingestion (e.g., via Snowpipe). TM (Ingestion), or any other defined function of the application. The application can act on behalf of consumer account 350 and execute the process programmatically.

[0073] Further as Figure 4 As shown, provider account 310 can create database role 360 ​​and grant access to configuration script 420 (also a stored procedure) to database role 360. Provider account 310 also grants database role 360 ​​to hidden role 440 of application shared object 430. Configuration script 420 can be used to fine-tune how the application runs. For example, if the application's function is to ingest data into consumer account 350, the consumer might want to configure the ingestion frequency or which tables it wants to ingest. This functionality can be provided by configuration script 420. Provider account 310 can directly grant hidden role 440 to exporter database role 480. Thus, a consumer with active administrator role 485 can use master database role 470 as the execution role to execute the shared configuration script 420 stored procedure.

[0074] Always using the master database role 470 to execute shared stored procedures (e.g., installation script 410) provides security for consumer account 350 because the privileges granted to master database role 470 are specific to the application's object / procedure or consumer object (which has been specifically granted by consumer account 350). In this model, installation script 410 (which consumer account 350 will not be able to access or analyze) will be confined to a sandbox-like perimeter, and consumer account 350 does not need to trust the code of the stored procedure installed by installation script 410.

[0075] When a provider upgrades the logic and code of its shared application, the native application framework 475 can be used to ensure that the upgraded functionality is replicated on the consumer side. In some embodiments, the native application framework 475 can take periodic “snapshots” of the application and save each snapshot. Each snapshot can resemble a version of the application and can include metadata about that application version. The metadata for each version can be stored and used for transitioning / migrating to a new version of the application. Some examples of the kinds of metadata saved by the native application framework 475 may include version data for the application version and state data for the application version. For example, state data may include an enable flag indicating that the application is enabled and active, and a disable flag indicating that the application is dormant, in which there are currently no active user tasks, and any calls to the application or local / shared objects result in an error. When an application is upgraded, it may only need to upgrade objects in the imported database to which it has privileges, and may not modify any account-level objects. In some embodiments, an application upgrade may include pausing the application's state, performing any necessary modifications, adding and / or removing objects and configurations of the application, and then resuming the application. Upgrades may require granting additional consumer-local objects / licenses to the application, which is performed through the importer database role 490, discussed in further detail above. In some embodiments, the native application framework 475 may prompt the user to grant the application the required additional consumer native objects / licenses.

[0076] In some embodiments, the native application framework 475 may provide the ability to record application usage metrics, detail how consumers use these applications, and provide such usage metric logs to the provider.

[0077] When providers share applications (e.g., by creating a list for them in a data exchange), they can include such usage metrics in the list's metadata so that consumers will be aware of the resources consumed through the application and can set quotas for their consumption budgets. For example, a provider can provide an indication of the resources (e.g., compute, storage resources) required to run the application in the list metadata, and any consumer interested in the application can set their own quotas accordingly.

[0078] In some embodiments, the native application framework 475 can monitor the execution of an application and generate execution logs that can be provided to consumers. In some embodiments, in response to determining that a shared application is not functioning correctly, a consumer can (via the native application framework 475) programmatically pause the execution of the application and share its execution logs with the provider. The native application framework can purge execution logs containing personal / sensitive data before sharing them with the provider. The provider can use the shared execution logs to fix any bugs / problems in the application and share updated versions of the application. As discussed herein, consumers can programmatically upgrade to updated versions of the application. Furthermore, the application can generate metrics that consumers can monitor (e.g., via the native application framework 475). The native application framework 475 can also enable consumers to define criteria for issuing alerts, such as when certain metrics reach thresholds. The application may also generate events for consumers when it encounters an anomaly.

[0079] In some embodiments, the native application framework 475 may also utilize extensibility mechanisms, such as connector functionality, to invoke any appropriate third-party service / endpoint. The native application framework 475 may utilize any language supported by the data exchange (e.g., Javascript, Java, and Python), thereby enabling native applications to be written in any language supported by the data exchange.

[0080] As can be seen, embodiments of this disclosure enable providers to develop applications and processes to set up and install application functionality using data exchange primitives. Providers can "promote" applications using the list discussed above regarding general data sharing and can make applications available to consumers through a shareable container with appropriate RBAC controls, ensuring that consumers are granted access only to public artifacts of the native application. Consumers can programmatically discover these applications and install them as sandbox containers into their own accounts. Applications can then be programmatically configured using authorization credentials, the computing resources required by the application instance, and other application-specific configurations that may require external setup. Consumers can programmatically configure and manage the application's lifecycle.

[0081] Figures 5A-5C The code implementation of an example application sharing process 500 according to some embodiments of this disclosure is shown. Figure 5A The provider-side code for an example sharing process is shown. (Example code follows.) Figure 5AAs shown, the provider can create a database ("createdatabase time_DB"), and then create a schema within the database ("create schema time_db.installer_schema"), in which the installation script 505 will reside. The provider can define the installation script (time_db.installer_schema.installer()) according to the application's desired functionality.

[0082] exist Figures 5A-5C In the example, the application's basic functionality is to periodically insert timestamps into a table. More specifically (see [reference needed]). Figure 5A The provider can define installation script 505 to create a timestamp schema in which the application can execute ("create schema time_schema"). The provider can also define installation script 505 to create a timestamp table that can record timestamps ("create table time_schema.time_table(ts_timestamp)") and create a timestamp insertion procedure to monitor timestamps and insert them into the table ("create procedure time_schema.record_time()"). The installation script can also be defined to create a service startup procedure ("create procedure time_schema.start_service(wh_name string)") that periodically calls the timestamp insertion procedure.

[0083] Installation script 505 can also be defined as having the ability to grant access to the exporter database role (app_exporter) created by the native application framework discussed above, including access to the schema storing installation script 505 ("grant usage onschema time_schema to database role app_exporter"), access to the service start procedure ("grant usage on procedure time_schema.start_service(string) to database role app_exporter"), and access to the timestamp table ("grant select on table time_schema.time_table to database role app_exporter"). This is because, by default, consumer accounts cannot access any of these objects or procedures, as discussed in further detail above. Figure 5AAs can be seen from this, the installation script 505 does not have authorized access to the timestamp insertion process. Therefore, when installing the application, consumer account 350 cannot see the underlying code of the timestamp insertion process or directly access the timestamp insertion process in other ways, but it can call it using the startup service process.

[0084] Now for reference Figure 5B The provider can create an application share in the same way as creating a regular share ("createshare time_share installer"), and attach the installation script (time_db.installer_schema.installer()) to the application share. The provider can then grant the application share the necessary privileges (such as...). Figure 5B The privilege set 510 in the document includes usage on the database (time_db), usage on the schema (installer_schema), and usage on the installation script 505 (installer_schema.installer).

[0085] Figure 5C The example application, Shared Process 500, is shown in the consumer-side code. (Example code follows.) Figure 5C As shown, when consumers run the command to view available shares (“show shares”), they can see the share time.share and can create a database named time_app (the imported database) from the share time.share (“create or replace database time_app from share nativeappsorg.native_apps_provider.time_share”). This automatically triggers the setup process of creating the timestamp schema (time_schema), the timestamp table (time_table), and the start service procedure (start_service(string)). If consumers run the command to display schemas (“show schemas”), they will see the schema time_schema. If consumers run the command to display tables (“show tables”), they will see the timestamp table (time_table). If consumers run the command to display procedures (“show procedures”), they will see the start service procedure (start_service(string)), but will not see the timestamp insertion procedure (record_time()).

[0086] At this point, the consumer account will grant the application the necessary privileges to run a task (e.g., a service startup procedure) within that consumer account (“grant execute task on account to database time_app”), and grant the application usage privileges on the data warehouse (the imported database) in which it will execute (“grant usage on warehouse time_service_wh to database time_app”). The consumer account can then execute the service startup procedure, which can run a timestamp insertion procedure.

[0087] Figure 7 This is a flowchart of a method 700 for sharing an application among database users, according to some embodiments of this disclosure. Method 700 may be executed by processing logic, which may include hardware (e.g., circuitry, dedicated logic, programmable logic, processor, processing device, central processing unit (CPU), system-on-a-chip (SoC), etc.), software (e.g., instructions that run / execute on the processing device), firmware (e.g., microcode), or a combination thereof. In some embodiments, method 700 may be deployed in a cloud 305 (e.g., cloud deployment 305). Figure 3 and Figure 4 The processing device (as shown) is used to execute it.

[0088] Also refer to Figure 4After creating database DB1 and schema 320A, in block 705, provider account 310 can generate installation script 410 and store it as a stored procedure in schema 320A. As discussed in further detail here, provider account 310 can define installation script 410 with the necessary functionality to install the application (including any objects and procedures required by the application) in consumer account 350. In block 710, provider account 310 can create application shared object 430 in the same manner as creating a regular shared object and attach installation script 410 to application shared object 430. Provider account 310 can then grant application shared object 430 the necessary privileges, including use on database DB1, use on schema 320A, and use on installation script 410. When consumer account 350 runs commands to view available shares, they can see application shared object 430 and can import application shared object 430 to create imported database 460 from application shared object 430. In block 715, in response to the creation of the imported database 460, in block 720, the native application framework 475 can automatically trigger the execution of the installation script 410, which can create objects and tasks / procedures corresponding to the functions of the application in consumer account 350. For example, the installation script 410 can create a process that periodically contacts a third-party API and retrieves data from the third-party API into the imported database 460 for processing. Since the application must access data and perform various functions, the imported database 460 DB1 is no longer a read-only database, as it will include not only the application-shared objects 430 from provider account 310 (read-only), but also objects created locally within the imported database through the stored procedures / installation script 410 attached to the application.

[0089] In block 725, the native application framework 475 can create a set of database roles as part of the application installation to facilitate shared processes. More specifically, the native application framework 475 can create a master database role 470, which can represent the application itself and control the use or execution of any objects or processes corresponding to the application's functionality. In other words, the master database role 470 controls the application, similar to a top-level role in an account. The native application framework 475 can also create an exporter database role 480, which the installation script 410 can grant licenses to during application installation for certain objects and / or processes created by it (installation script 410). The native application framework 475 can also create an importer database role 490. When objects / licenses of consumer account 350 are granted to the application, the importer database role 490 can automatically acquire those objects / licenses. The native application framework 475 can automatically grant the importer database role 490 to the master database role 470, so that the master database role 470 can assume (through the importer database role 490) all licenses granted to the application. The native application framework 475 can automatically grant the exporter database role 480 to the administrator role 485 (i.e., the role of the consumer account 350 through which it installs the application), where the administrator role 485 is an account-level role of the consumer account 350. As a result, certain objects and / or processes granted to the exporter database role 480 by the installation script 410 may be visible / accessible to the consumer account 350 (e.g., accessible by the administrator role 485). For example, during the installation of objects and processes required for application operation, the installation script 410 may create schema S2 and table T2. The installation script 410 can be defined to grant both the exporter database role 480 and the importer database role 490 access to schema S2, and to grant the exporter database role 480 selective access to T2, thus giving it selective access to T2. By defining the basic functionality of the native application framework 475, the exporter database role 480 is granted the administrator role 485 (i.e., the role that executes the installation script). Therefore, consumer account 350 (e.g., through administrator role 485) can have selective access to table T2.

[0090] In this way, the master database role 470 can provide fine-grained access to objects of the application shared object 430 through the exporter database role 480 (as opposed to an all-or-nothing approach), as discussed further in detail herein. It should be noted that when the consumer account 350 installs the application, the installation script 410 itself is not granted the exporter database role 480, and therefore the consumer account 350 cannot see it. Similarly, any data created by the installation script 410 (e.g., objects, schemas, tables, etc.) is invisible / inaccessible to any consumer role by default unless the installation script 410 instructs them to be granted the exporter database role 480. However, if any object or procedure is not granted the exporter database role 480, then it is meant to be used solely by the application.

[0091] Figure 8 A schematic representation of a machine in an example form of a computer system 800 is shown, wherein a set of instructions causes the machine to perform any or more methods described herein for replicating shared objects to a deployment. More specifically, the machine can modify a shared object of a first account into a global object, wherein the shared object includes authorization metadata indicating shared authorization for a set of objects in a database. The machine can create a local copy of the shared object on the deployment based on the global object in a second account located in the deployment, and replicate a set of objects from the database to a local database copy on the deployment; and refresh the shared authorization for the local copy of the shared object.

[0092] In alternative embodiments, the machine may be connected (e.g., networked) to other machines on a local area network (LAN), intranet, extranet, or the Internet. The machine may operate as a server or client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, web appliance, server, network router, switch or bridge, hub, access point, network access control device, or any machine capable of executing (sequentially or otherwise) a set of instructions specifying the action to be taken by the machine. Furthermore, although only a single machine is shown, the term "machine" should also be understood to include any set of machines that individually or in association execute a set (or more) of instructions to implement any one or more of the methods discussed herein. In one embodiment, computer system 800 may represent a server.

[0093] An exemplary computer system 800 includes a processing device 802, a main memory 804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM)), a static memory 805 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 818, which communicate with each other via a bus 830. Any signals provided on the various buses described herein may be time-multiplexed with other signals and provided via one or more common buses. Furthermore, interconnections between circuit components or blocks may be represented as buses or single signal lines. Each of the buses may optionally be one or more single signal lines, and each of the single signal lines may optionally be a bus.

[0094] The computing device 800 may further include a network interface device 808 capable of communicating with the network 820. The computing device 800 may also include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 812 (e.g., a keyboard), a cursor control device 814 (e.g., a mouse), and a sound signal generation device 815 (e.g., a speaker). In one embodiment, the video display unit 810, the alphanumeric input device 812, and the cursor control device 814 may be combined into a single component or device (e.g., an LCD touchscreen).

[0095] Processing device 802 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets, or a processor implementing combinations of instruction sets. Processing device 802 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 802 is configured to execute application-shared instructions 825 to perform the operations and steps discussed herein.

[0096] Data storage device 818 may include machine-readable storage medium 828 on which one or more sets of application-shared instructions 825 (e.g., software) embodying any or more of the functional methods described herein are stored. During execution of the application-shared instructions 825 by computer system 800, the application-shared instructions 825 may also reside wholly or at least partially in main memory 804 or in processing device 802; main memory 804 and processing device 802 also constitute machine-readable storage media. The application-shared instructions 825 may also be transmitted or received on network 820 via network interface device 808.

[0097] As described herein, the machine-readable storage medium 828 can also be used to store instructions for performing methods to determine the functionality to be compiled. Although the machine-readable storage medium 828 is shown as a single medium in exemplary embodiments, the term "machine-readable storage medium" should be considered to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that store one or more sets of instructions. Machine-readable media includes any mechanism for storing information in a machine-readable (e.g., computer-readable) form (e.g., software, processing applications). Machine-readable media can include, but is not limited to, magnetic storage media (e.g., floppy disks); optical storage media (e.g., CD-ROMs); magneto-optical storage media; read-only memory (ROM); random access memory (RAM); erasable programmable memory (e.g., EPROM and EEPROM); flash memory; or another type of medium suitable for storing electronic instructions.

[0098] Unless otherwise expressly stated, terms such as “receive,” “route,” “grant,” “determine,” “publish,” “provide,” “designate,” “encode,” etc., refer to actions and processes performed or implemented by a computing device that manipulate and convert data represented as physical (electronic) quantities within the registers and memory of the computing device into other data similarly represented as physical quantities within the memory or registers of the computing device or other such information storage, transmission, or display devices. Furthermore, as used herein, the terms “first,” “second,” “third,” “fourth,” etc., are labels used to distinguish different elements and do not necessarily have ordinal meanings based on their numerical names.

[0099] The examples described herein also relate to apparatus for performing the operations described herein. This apparatus may be specifically constructed for a desired purpose, or it may comprise a general-purpose computing device selectively programmed by a computer program stored in a computing device. Such a computer program may be stored in a computer-readable, non-transitory storage medium.

[0100] The methods and illustrative examples described herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used based on the teachings described herein, or it can be demonstrated that it is convenient to construct more specialized devices to perform the desired method steps. As shown in the description above, the desired structures of various such systems will emerge.

[0101] The above description is intended to be illustrative and not restrictive. Although this disclosure has been described with reference to specific illustrative examples, it will be appreciated that this disclosure is not limited to the described examples. The scope of this disclosure should be determined by referring to the appended claims and the full scope of the equivalents given by the claims.

[0102] As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that, when used herein, the terms “comprises,” “comprising,” “includes,” and / or “including” specify the presence of the stated feature, integer, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Therefore, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

[0103] It should also be noted that in some alternative implementations, the functions / actions mentioned may not occur in the order shown in the diagram. For example, depending on the functions / actions involved, two diagrams shown consecutively may actually be executed substantially simultaneously, or sometimes in reverse order.

[0104] Although the method operations are described in a specific order, it should be understood that other operations may be performed between the described operations, the described operations may be adjusted so that they occur at slightly different times, or the described operations may be distributed in a system that allows processing operations to occur at various intervals associated with the processing.

[0105] Various units, circuits, or other components can be described or required to be "configured to" or "configurable to" perform one or more tasks. In such a context, the phrase "configured to" or "configurable to" is used to indicate a structure by indicating that the unit / circuit / component includes a structure (e.g., a circuit) that performs one or more tasks during operation. Thus, it can be said that the specified unit / circuit / component is configured to perform a task, or can be configured to perform a task, even when the specified unit / circuit / component is not currently in operation (e.g., not switched on). Units / circuit / components used with the "configured to" or "configurable to" language include hardware—e.g., circuits, memory storing program instructions that can be executed to perform operations, etc. Declaring that a unit / circuit / component is "configured to" perform one or more tasks, or is "configurable to" perform one or more tasks, is clearly not intended to invoke 35 USC 112, paragraph 6, for that unit / circuit / component. Additionally, "configured to" or "configurable to" can include general-purpose structures (e.g., general-purpose circuits) manipulated by software and / or firmware (e.g., FPGAs or general-purpose processors executing software) to operate in a manner capable of performing the tasks in discussion. "Configured to" can also include adapting a manufacturing process (e.g., a semiconductor manufacturing facility) to manufacture devices (e.g., integrated circuits) suitable for implementing or performing one or more tasks. It is explicitly stated that "configurable to" does not apply to blank media, unprogrammed processors or unprogrammed general-purpose computers, or unprogrammed programmable logic devices, programmable gate arrays, or other unprogrammed devices, unless accompanied by a programmed medium that endows the unprogrammed device with the ability to be configured to perform the disclosed functions.

[0106] Any combination of one or more computer-usable or computer-readable media may be used. For example, computer-readable media may include one or more of portable computer disks, hard disks, random access memory (RAM) devices, read-only memory (ROM) devices, erasable programmable read-only memory (EPROM or flash memory) devices, portable optical disc read-only memory (CDROM), optical storage devices, and magnetic storage devices. Computer program code for performing the operations of this disclosure may be written in any combination of one or more programming languages. Such code may be compiled from source code into computer-readable assembly language or machine code suitable for a device or computer on which the code will be executed.

[0107] Implementations can also be carried out in a cloud computing environment. In this specification and the appended claims, “cloud computing” can be defined as a model that enables ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services), which can be rapidly configured (including via virtualization) and released with minimal management effort or service provider interaction, and then scaled accordingly. The cloud model can consist of various features (e.g., on-demand self-service, widespread network access, resource pooling, rapid elasticity, and measurable services), service models (e.g., Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”)), and deployment models (e.g., private cloud, community cloud, public cloud, and hybrid cloud).

[0108] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, including one or more executable instructions for implementing a specified logical function. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented by a system based on dedicated hardware or a combination of dedicated hardware and computer instructions that performs the specified function or action. These computer program instructions may also be stored in a computer-readable medium that can instruct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable medium produce an article of art including instruction means that implement the function / action specified in the flowchart and / or one or more block diagram blocks.

[0109] For purposes of explanation, the foregoing description has been described with reference to specific embodiments. However, the illustrative discussion above is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. These embodiments were chosen and described in order to best explain the principles of the embodiments and their practical application, thereby enabling others skilled in the art to best utilize the embodiments and various modifications as may be adapted to the particular uses contemplated. Therefore, these embodiments should be considered illustrative rather than restrictive, and the invention is not limited to the details given herein, but can be modified within the scope and equivalents of the appended claims.

Claims

1. A method comprising: Define an installation script for installing applications in a data exchange, wherein the data exchange includes provider accounts and consumer accounts, wherein the provider accounts will share data assets with the consumer accounts; A shared object for the database is created in the provider account, and the installation script is attached to the shared object, wherein the shared object includes information for sharing the data assets in the database with the consumer account; and In response to creating an imported database in the consumer account based on the shared object: The installation script in the consumer account is automatically executed by the processing device to install the application, wherein the application includes a set of objects and a set of procedures that determine the functionality of the application; and A set of database roles is created to manage the execution of the application in the consumer account, wherein each database role in the set of database roles describes the access privileges granted to the application or the installation script within the consumer account.

2. The method according to claim 1, wherein, The consumer account does not have default access rights to any object in the set of objects, nor does it have default access rights to any procedure in the set of procedures of the application, and wherein the set of database roles includes: The first database role is used to control the execution of the application within the consumer account; and A second database role is granted by the installation script to access one or more of the set of objects and one or more of the set of processes of the application, wherein the second database role is granted an account-level role by the consumer account.

3. The method according to claim 2, further comprising: One or more of the set of objects and one or more of the set of processes are executed by the second database role, corresponding to the functions of the application.

4. The method according to claim 2, wherein, The set of database roles also includes a third database role, which is granted the object and permission of the consumer account in response to the application being granted the object and permission of the consumer account.

5. The method of claim 4, further comprising granting the third database role to the first database role, such that the first database role undertakes the granting of objects and permissions to the consumer account.

6. The method according to claim 2, further comprising: Grant the use of the configuration script to the hidden role of the shared object; Grant the hidden role of the shared object to the second database role; and Use the second database role to execute the configuration script to modify the functionality of the application.

7. The method according to claim 1, further comprising: A list for sharing the application is generated in the data exchange.

8. A system comprising: Memory; as well as A processing device operatively coupled to the memory, the processing device being used for: Define an installation script for installing applications in a data exchange, wherein the data exchange includes provider accounts and consumer accounts, wherein the provider accounts will share data assets with the consumer accounts; A shared object for the database is created in the provider account, and the installation script is attached to the shared object, wherein the shared object includes information for sharing the data assets in the database with the consumer account; and In response to creating an imported database in the consumer account based on the shared object: The installation script in the consumer account is executed automatically to install the application, wherein the application includes a set of objects and a set of procedures that determine the functionality of the application; and A set of database roles is created to manage the execution of the application in the consumer account, wherein each database role in the set of database roles describes the access privileges granted to the application or the installation script within the consumer account.

9. The system according to claim 8, wherein the set of database roles includes: The first database role is used to control the execution of the application in the consumer account; and A second database role is granted by the installation script to access one or more of the set of objects and one or more of the set of processes of the application, wherein the second database role is granted an account-level role by the consumer account.

10. The system according to claim 9, wherein, The consumer account does not have default access rights to any of the objects in the set of objects, nor does it have default access rights to any of the processes in the set of processes of the application, and the processing device is further configured to: Through the second database role, one or more of the set of objects and one or more of the set of processes corresponding to the functions of the application are executed.

11. The system according to claim 9, wherein, The set of database roles also includes a third database role, which is granted the object and permission of the consumer account in response to the application being granted the object and permission of the consumer account.

12. The system according to claim 11, wherein, The processing equipment is also used for: The third database role is granted to the first database role, thereby enabling the first database role to grant objects and permissions to the consumer account.

13. The system according to claim 9, wherein, The processing equipment is also used for: Grant the use of the configuration script to the hidden role of the shared object; Grant the hidden role of the shared object to the second database role; and Use the second database role to execute the configuration script to modify the functionality of the application.

14. The system according to claim 8, wherein, The processing equipment is also used for: A list for sharing the application is generated in the data exchange.

15. A non-transitory computer-readable medium having instructions stored thereon, the instructions causing the processing device, when executed by a processing device, to: Define an installation script for installing applications in the data exchange, where, The data exchange includes provider accounts and consumer accounts, wherein the provider accounts will share data assets with the consumer accounts; A shared object for the database is created in the provider account, and the installation script is attached to the shared object, wherein the shared object includes information for sharing the data assets in the database with the consumer account; and In response to creating an imported database in the consumer account based on the shared object: The processing device automatically executes the installation script in the consumer account to install the application, wherein the application includes a set of objects and a set of procedures that determine the functionality of the application; and A set of database roles is created to manage the execution of the application in the consumer account, wherein each database role in the set of database roles describes the access privileges granted to the application or the installation script within the consumer account.

16. The non-transitory computer-readable medium of claim 15, wherein the consumer account does not have default access rights to any of the set of objects and does not have default access rights to any of the set of processes of the application, and wherein the set of database roles includes: The first database role is used to control the execution of the application in the consumer account; and A second database role is granted by the installation script to access one or more of the set of objects and one or more of the set of processes of the application, wherein the second database role is granted an account-level role by the consumer account.

17. The non-transitory computer-readable medium according to claim 16, wherein, The processing equipment is also used for: Through the second database role, one or more of the set of objects and one or more of the set of processes corresponding to the functions of the application are executed.

18. The non-transitory computer-readable medium according to claim 16, wherein, The set of database roles also includes a third database role, which is granted the object and permission of the consumer account in response to the application being granted the object and permission of the consumer account.

19. The non-transitory computer-readable medium according to claim 18, wherein, The processing equipment is also used for: The third database role is granted to the first database role, thereby enabling the first database role to grant objects and permissions to the consumer account.

20. The non-transitory computer-readable medium according to claim 16, wherein, The processing equipment is also used for: Grant the use of the configuration script to the hidden role of the shared object; Grant the hidden role of the shared object to the second database role; and Use the second database role to execute the configuration script to modify the functionality of the application.

Images