Splunk Inc.

Microsoft Technology Licensing, LLC

Andrew Peters

Alexander Douglas James

Diego Bernardo Vega

Rowan Laurence Miller

Arun Ramani

Jeffrey Michael Derstadt

Arthur John Cerdic Vickers

Christopher Madden Pride

Timothy A Laverty

Manu Jose

Scott Calvert

Jindrich Dinga

Thomas Allan Haggie

Clark Eugene Mullen

Finlay Cannon

Ioan Popa

Jacob Sebastian Stark

Jonathan Ng

Barbara Janczer

Venkatasubramanian Jayaraman

Bardhi Shtylla

Ganesh Jothikumar

Salih Ammar Wajih Zainulabdeen

Amy Joanna Sutedja

Ankur Dalsukhbhai Bambharoliya

Vinayak Bhakta

Arthur John Cedric Vickers

Systems and methods are described for a query conversion system to convert a first query string from a first version of a query language to a second version of the query language. The query conversion system may be associated with a tokenizer and parser, code converter, compatibility library, and a query formatter. The tokenizer and parser may tokenize and parse a query string to create a first node tree with commands. The code converter may parse the first node tree while using the compatibility library to convert the commands and generate a second node tree. The query formatter may create a second query string executable by the second version of the query language.

Language conversion system

A system is described that receives a query model of a query that includes one or more query commands. The query model includes a command model that corresponds to at least query command of the one or more query commands. The system uses the command model to generate an interactive action model summary and causes a user interface to display the query and the interactive action model summary in a query actions panel. A modification to the query in the user interface causes an update to the query actions panel and a modification to the action model summary causes an update to the at least one query command of the query.

Bi-directional query updates in a user interface

Systems and methods are described for implementing programmatic input/output (I/O) routing to datasets with user-defined partitions while providing unhandled data protection. As disclosed herein, a user may define a dataset as including one or more partitions, each partition including criteria for storing data objects written to the partitioned dataset in the individual partitions. Data objects written to the dataset can then be evaluated according to the criteria, and routed to an appropriate partition. To provide unhandled data protection, a dataset definition can include a default partition to which data objects are routed when the data object fails to satisfy the criteria of any of the set of user-defined partitions identified in the specification. Processing I/O operations according to a user-defined partitioning schema can enable data objects to be arranged according to any partitioning schema without tethering the partitioning to a particular underlying storage system.

Unhandled data protection for programmatic input/output routing to datasets with user-defined partitions

Systems and methods are disclosed for annotating a metadata catalog in a data intake and query system based on a query received by the data intake and query system. The metadata catalog can store information about datasets associated with the data intake and query system, including dataset configuration records of the datasets, which can be used to process queries for execution by the data intake and query system. The data intake and query system can receive a query identifying a set of data to be processed and a manner of processing the set of data. The data intake and query system can parse the query to identify datasets and/or data fields associated with the query. Based on the identified datasets and/or fields, the data intake and query system can generate one or more annotations, and use the annotations to update the metadata catalog.

Revising catalog metadata based on parsing queries

Systems and methods are disclosed for flexibly applying a query term to heterogeneous data. A query system can receive a query that includes a data-determinant query term. As the system executes the query it can generate interim search results. As the system query processes the interim search results based on the query, it can apply the data-determinant query term to records of the interims search results based on the structure of the records.

Data-determinant query terms

Systems and methods are disclosed for annotating a metadata catalog in a data intake and query system based on a detected change to the metadata catalog. The metadata catalog can store information about datasets associated with the data intake and query system, including dataset configuration records of the datasets, which can be used to process queries for execution by the data intake and query system. Based on a detected change to the metadata catalog, such as a manual or system annotation, the data intake and query system can generate additional annotations for the metadata catalog and use the annotations to update the metadata catalog.

Automatically generating metadata for a metadata catalog based on detected changes to the metadata catalog

Techniques are described herein that are capable of translating programming language patterns into database schema patterns. Examples of a programming language pattern include but are not limited to a source code pattern, an intermediate language code pattern, metadata associated with a source code pattern, metadata associated with an intermediate language code pattern, or any combination thereof. The programming language patterns may define objects that are included in an object model. Database schema patterns that define a database are automatically (e.g., inferentially) created based on respective programming language patterns that define objects of an object model. The programming language patterns are automatically mapped to the respective database schema patterns.

Translating metadata associated with code patterns into database schema patterns

Translating programming language patterns into database schema patterns

A balance is provided between automation of repetitive database creation and configuration efforts, on the one hand, and flexibility to depart from prior configurations, on the other hand, to assist developers with aspects of database initialization. An application domain includes data context instances, database connections, object models mapped by an object-relational mapper, and database initializers. Upon the first attempted runtime use of a particular database connection&#x2014;data context instance&#x2014;object model combination, a database initializer is invoked. Initializers may check to see if the database exists, (re)generate a database and schema based on the object model, determine whether the database is compatible with the current object model, delete the database and its schema, seed data, modify database indexes, and/or migrate an existing database, for example. A custom initializer can run developer-supplied code as desired to place the database in a known state for use by the application.

Object-relational mapped database initialization

Fluent API Patterns promote balance in managing object persistence. Code which obtains an object-relational mapper session contains API Patterns that manipulate persistence ignorant objects using calls to a fluent interface. When the developer's code executes, it may manipulate an object state, a property state, and/or a persistent relationship of the persistence ignorant object. The code may implement API Patterns such as find-change-save, current-value-original-value, nested-property, incremental-graph-load, incremental-graph-filtered-load, property-modification, dictionary, and/or other API Patterns. Additional examples of API Patterns include an API Pattern to read current, original, and database values for all properties of an entity; an API Pattern to set current and/or original values from another object; and an API Pattern to create a cloned object containing current, original, and/or database values. In any or all of these situations, the API Pattern calls to the fluent interface may be written in a strongly typed language.

Fluent API patterns for managing object persistence

Growing community of inventors

Sammamish, WA, United States of America

Andrew Peters