Abstract: Methods and apparatus for updating a denormalized database object after updating, deleting, or inserting a record in a source database object are described. A first operation on a source database object that involves a record of the source database object being updated, deleted, or inserted is performed. A first part of a corresponding second operation involving a respective record of the denormalized database object being updated, deleted, or inserted is performed. A query result that references an aggregate field of a set of records in the denormalized database object is altered. The altering includes an aggregation operation using values in the query result being performed and altering that part of the query result that includes the aggregate field of the set of records. A second part is optionally performed to complete the corresponding second operation and update the denormalized database object.

Abstract: An indication of an action is received through and application program interface (API) provided by one or more hardware processing devices. The action corresponds to communication with a specified party. Multiple disparate tables stored in at least one database of a of a database environment associated with the one or more hardware processing devices are searched for records having the field property corresponding to the specified party. The field property from the corresponding multiple disparate tables are evaluated. A unified field property is determined based on the evaluation of the field property from the corresponding multiple disparate tables. The unified field property is returned through the API.

Abstract: Methods and apparatus for updating a denormalized database object after updating, deleting, or inserting a record in a source database object are described. A first operation on a source database object that involves a record of the source database object being updated, deleted, or inserted is performed. A first part of a corresponding second operation involving a respective record of the denormalized database object being updated, deleted, or inserted is performed. A query result that references an aggregate field of a set of records in the denormalized database object is altered. The altering includes an aggregation operation using values in the query result being performed and altering that part of the query result that includes the aggregate field of the set of records. A second part is optionally performed to complete the corresponding second operation and update the denormalized database object.

Abstract: Methods and systems for using consent policies to determine whether to proceed with actions relative to persons based on a hierarchy of consent values for that person are described. Responsive to a query, records are retrieved which pertain to a person's consent for another entity to perform an action relative to the person in view of data privacy laws. A consent policy is selected. The selected consent policy includes rules that are configurable to reflect a manner to comply with data privacy laws. The selected consent policy is applied to the records. Applying the selected consent policy comprises applying rules to find a result for a second level of the hierarchy of consent values, determining a result for a first level of the hierarchy of consent values, and applying rules to determine whether to proceed with the action relative to the person.

Abstract: Predictive execution of query flows in an application aware database environment. A repository of previously received and registered database queries along with at least corresponding metadata having information about database query flows generating the database queries is maintained. Application metadata corresponding to a subsequent database query is received. The repository is checked to determine if the application metadata matches one of the previously received and registered database query flows. One or more queries corresponding to the query flow from the repository is/are retrieved if a match is determined. Execution of the retrieved one or more database queries is started prior to receiving the query from outside the repository.

Abstract: An indication of an action is received through and application program interface (API) provided by one or more hardware processing devices. The action corresponds to communication with a specified party. Multiple disparate tables stored in at least one database of a of a database environment associated with the one or more hardware processing devices are searched for records having the field property corresponding to the specified party. The field property from the corresponding multiple disparate tables are evaluated. A unified field property is determined based on the evaluation of the field property from the corresponding multiple disparate tables. The unified field property is returned through the API.

Abstract: Methods and apparatus for updating a denormalized database object after updating, deleting, or inserting a record in a source database object are described. A first operation on a source database object that involves a record of the source database object being updated, deleted, or inserted is performed. A first part of a corresponding second operation involving a respective record of the denormalized database object being updated, deleted, or inserted is performed. A query result that references an aggregate field of a set of records in the denormalized database object is altered. The altering includes an aggregation operation using values in the query result being performed and altering that part of the query result that includes the aggregate field of the set of records. A second part is optionally performed to complete the corresponding second operation and update the denormalized database object.

Abstract: At least one database table of denormalized values corresponding to selected values of field properties in records across multiple disparate tables of the database environment is maintained. A structured query is received through a structured query language application program interface (API). The structured query to request a listing of records across the multiple disparate tables of the database environment. The database table is searched for indications corresponding to records across the multiple disparate tables of the database environment corresponding to the selected values indicating communication with a specified party. A listing of records from across the multiple disparate tables that satisfy the selected values is returned through the structured query language API.

Abstract: Application-aware database environments. A repository of previously received and registered database queries is maintained that includes at least corresponding metadata having information about an application generating the database queries. A subsequent database query and application metadata corresponding to the subsequent database query can be received. The repository to determine if the subsequent database query and application metadata match one of the previously received database queries and application metadata. A matching previously received database query is retrieved from the repository if a match is determined. The retrieved database query is executed.

Abstract: Methods and systems for using consent policies to determine whether to proceed with actions relative to persons based on a hierarchy of consent values for that person are described. Responsive to a query, records are retrieved which pertain to a person's consent for another entity to perform an action relative to the person in view of data privacy laws. A consent policy is selected. The selected consent policy includes rules that are configurable to reflect a manner to comply with data privacy laws. The selected consent policy is applied to the records. Applying the selected consent policy comprises applying rules to find a result for a second level of the hierarchy of consent values, determining a result for a first level of the hierarchy of consent values, and applying rules to determine whether to proceed with the action relative to the person.

Abstract: A method for responding to a consent request for an action based on a set of records is described. The method includes receiving the consent request, including a set of identifiers and the action for obtaining consent; locating a first record of a first object type and a second record of a second data type, wherein the first record corresponds to a first identifier in the set of identifiers, the second record corresponds to a second identifier of the set of identifiers, and one or more of the first and second records includes consent information for performing the action; determining a final response based on the first and second records, wherein the final response includes at least one proceed element that indicates whether consent exists for the action based on at least the first and second records; and returning the final response as a response.

Abstract: Methods and apparatus for updating a denormalized database object after updating, deleting, or inserting a record in a source database object are described. A first operation on a source database object that involves a record of the source database object being updated, deleted, or inserted is performed. A first part of a corresponding second operation involving a respective record of the denormalized database object being updated, deleted, or inserted is performed. A query result that references an aggregate field of a set of records in the denormalized database object is altered. The altering includes an aggregation operation using values in the query result being performed and altering that part of the query result that includes the aggregate field of the set of records. A second part is optionally performed to complete the corresponding second operation and update the denormalized database object.

Abstract: At least one database table of denormalized values corresponding to selected values of field properties in records across multiple disparate tables of the database environment is maintained. A structured query is received through a structured query language application program interface (API). The structured query to request a listing of records across the multiple disparate tables of the database environment. The database table is searched for indications corresponding to records across the multiple disparate tables of the database environment corresponding to the selected values indicating communication with a specified party. A listing of records from across the multiple disparate tables that satisfy the selected values is returned through the structured query language API.

Abstract: An indication of an action is received through and application program interface (API) provided by one or more hardware processing devices. The action corresponds to communication with a specified party. Multiple disparate tables stored in at least one database of a of a database environment associated with the one or more hardware processing devices are searched for records having the field property corresponding to the specified party. The field property from the corresponding multiple disparate tables are evaluated. A unified field property is determined based on the evaluation of the field property from the corresponding multiple disparate tables. The unified field property is returned through the API.

Abstract: Predictive execution of query flows in an application aware database environment. A repository of previously received and registered database queries along with at least corresponding metadata having information about database query flows generating the database queries is maintained. Application metadata corresponding to a subsequent database query is received. The repository is checked to determine if the application metadata matches one of the previously received and registered database query flows. One or more queries corresponding to the query flow from the repository is/are retrieved if a match is determined. Execution of the retrieved one or more database queries is started prior to receiving the query from outside the repository.

Abstract: Application-aware database environments. A repository of previously received and registered database queries is maintained that includes at least corresponding metadata having information about an application generating the database queries. A subsequent database query and application metadata corresponding to the subsequent database query can be received. The repository to determine if the subsequent database query and application metadata match one of the previously received database queries and application metadata. A matching previously received database query is retrieved from the repository if a match is determined. The retrieved database query is executed.

Abstract: Integrated fuzzing techniques are described. A fuzzing system may employ a container configured as a separate component that can host different target pages to implement fuzzing for an application. A hosted target file is loaded as a subcomponent of the container and parsed to recognize functionality of the application invoked by the file. In at least some embodiments, this involves building a document object model (DOM) for a browser page and determining DOM interfaces of a browser to call based on the page DOM. The container then operates to systematically invoke the recognized functionality to cause and detect failures. Additionally, the container may operate to perform iterative fuzzing with multiple test files in an automation mode. Log files may be created to describe the testing and enable both self-contained replaying of failures and coverage analysis for multiple test runs.

Abstract: Integrated fuzzing techniques are described. A fuzzing system may employ a container configured as a separate component that can host different target pages to implement fuzzing for an application. A hosted target file is loaded as a subcomponent of the container and parsed to recognize functionality of the application invoked by the file. In at least some embodiments, this involves building a document object model (DOM) for a browser page and determining DOM interfaces of a browser to call based on the page DOM. The container then operates to systematically invoke the recognized functionality to cause and detect failures. Additionally, the container may operate to perform iterative fuzzing with multiple test files in an automation mode. Log files may be created to describe the testing and enable both self-contained replaying of failures and coverage analysis for multiple test runs.

Abstract: Integrated fuzzing techniques are described. A fuzzing system may employ a container configured as a separate component that can host different target pages to implement fuzzing for an application. A hosted target file is loaded as a subcomponent of the container and parsed to recognize functionality of the application invoked by the file. In at least some embodiments, this involves building a document object model (DOM) for a browser page and determining DOM interfaces of a browser to call based on the page DOM. The container then operates to systematically invoke the recognized functionality to cause and detect failures. Additionally, the container may operate to perform iterative fuzzing with multiple test files in an automation mode. Log files may be created to describe the testing and enable both self-contained replaying of failures and coverage analysis for multiple test runs.

Abstract: Integrated fuzzing techniques are described. A fuzzing system may employ a container configured as a separate component that can host different target pages to implement fuzzing for an application. A hosted target file is loaded as a subcomponent of the container and parsed to recognize functionality of the application invoked by the file. In at least some embodiments, this involves building a document object model (DOM) for a browser page and determining DOM interfaces of a browser to call based on the page DOM. The container then operates to systematically invoke the recognized functionality to cause and detect failures. Additionally, the container may operate to perform iterative fuzzing with multiple test files in an automation mode. Log files may be created to describe the testing and enable both self-contained replaying of failures and coverage analysis for multiple test runs.