Selectively publishing an event responsive to an operation on a database in a transaction which is rolled back or committed

#One or more implementations relate to the field of event publishing; and more specifically, to publishing an event responsive to an operation on a database.

#A transaction is a unit of work performed on a database. For example, a transaction may include one or more insertions, updates, and/or deletions of one or more records in a database. A transaction can be rolled back or committed. Rolling back a transaction on a database means returning the database to its state before the transaction was started; e.g., when a transaction includes inserting a record in a database, rolling back the transaction includes removing the record, if inserted, from the database. In contrast, committing a transaction means completing the unit of work on the database; e.g., when a transaction includes inserting, updating, and/or deleting one more records in a database, committing the transaction includes performing the inserting, updating, and/or deleting the records.

#An event is an identifiable unit of data that conveys information about an occurrence or lack of occurrence in a computing system. Events can relate to operations that occur in a database system. For example, an event may convey that a record of a database has been updated, deleted, or inserted. Typically, an event includes one or more attributes. In some tools, an event is associated with a topic to which one or more consumers are subscribed; e.g., in a publish-subscribe messaging system.

#The following figures use like reference numbers to refer to like elements. Although the following figures depict various example implementations, alternative implementations are within the spirit and scope of the appended claims. In the drawings:

#FIG. 1A is a flow diagram showing operations for selectively publishing an event configured by a user to be published responsive to one or more records of a database being updated, deleted, or inserted in a transaction, according to some example implementations.

#FIG. 1B is a block diagram showing a system for selectively publishing an event in a datastore, according to some example implementations.

#The following description describes implementations for selectively publishing an event configured by a user to be published responsive to an operation being performed on a database in a transaction. Implementations are described that involve one or more records of a database being updated, deleted, or inserted. However, one of skill in the art will recognize that selectively publishing an event published responsive to other kinds of transactions are within the spirit and scope of the invention. For example, implementations described herein support selectively publishing an event configured by a user to be published responsive to 1) creating, altering, or dropping a database object in a transaction (e.g., a transaction involving data definition language commands in Structured Query Language (SQL)); and/or 2) granting or revoking access privileges to a database object in a transaction (e.g., a transaction involving data control language statements in SQL), etc.

#Moreover, implementations described herein are not limited to relational database management systems (RDBMSs). Rather, implementations support selectively publishing an event configured by a user to be published responsive to an operation on any store of data that supports a transaction which may not be committed (e.g., which may be rolled back, which may not achieve data consistency in a timely manner, etc.).

#Implementations are not limited to any particular event-driven computing architecture. For example, an event described herein (which may also be referred to as a message) may be implemented as a message in a publish-subscribe messaging system which may include one or more different kinds of filtering (e.g., topic-based filtering, content-based filtering, role-based filtering, etc.). Thus, in some implementations, an event may be associated with a topic and publishing an event (e.g., to a datastore) causes the event to be transmitted to one or more consumers (i.e., sent such that the consumers are expected to receive the event) that have subscribed to the topic. However, this is exemplary and not limiting. In other implementations, message queueing may be used and thus publishing an event includes publishing the event to a message queue read by one or more consumers; alternatively, an event may be broadcast to a channel and read by one or more consumers that have connected to that channel, etc. Generally, a consumer consumes events (e.g., after subscribing to receive events in a publish-subscribe messaging system, after registering to receive events from a message queue, etc.). In some implementations, the consumer can be used for gaining insight on the data included in an event, for gaining insight on the operations and actions performed in an application and/or electronic device, and/or for gaining insight on the operations of a database system (e.g., database server 144). In some implementations, a consumer may be implemented in a distributed environment, where multiple event consumers can be implemented on one or more electronic devices.