Abstract: Content deployment systems and methods are provided for continuously integrating and deploying selected content items from a plurality of content sources into a specific release as part of the specific release. For example, a first content source stores a plurality of first content items for potential inclusion in the specific release. A manifest record for the specific release specifies release items that are allowed to be part of the specific release. A proxy can periodically retrieve selected ones of the first content items that are specified in the manifest record, and push them to a content publishing engine. Any content items that are not specified in the manifest record are rejected by the proxy. A processor of the content publishing engine can allow for continuous integration of the selected ones of the first content items into the specific release.

Abstract: Content deployment systems and methods are provided for integrating and deploying selected content items in a web content publishing process. A first content source can manage and store a plurality of first content items for potential inclusion in a specific release that is published as web content. Each content item can include one or more of: a set of directions for rendering web content and actual content that is rendered as web content. A content publishing module can store a manifest record that specifies release items that are allowed to be part of the specific release, and receive a content package object, from the first content source, that includes the first content items. It can then extract selected ones of first content items that are specified in the manifest record, and add them into a release object so that they are included as part of the specific release.

Abstract: Content deployment systems and methods are provided for continuously integrating and deploying selected content items from a plurality of content sources into a specific release as part of the specific release. For example, a first content source stores a plurality of first content items for potential inclusion in the specific release. A manifest record for the specific release specifies release items, by API name, that are allowed to be part of the specific release. A proxy can periodically retrieve selected ones of the first content items that are specified in the manifest record, and push them to a bulk API of a content publishing engine. Any content items that are not specified in the manifest record are rejected by the proxy. A processor of the content publishing engine can allow for continuous integration of the selected ones of the first content items into the specific release.

Abstract: Content deployment systems and methods are provided for continuously integrating and deploying selected content items from a plurality of content sources into a specific release as part of the specific release. For example, a first content source stores a plurality of first content items for potential inclusion in the specific release. A manifest record for the specific release specifies release items, that are allowed to be part of the specific release. A proxy can periodically retrieve selected ones of the first content items that are specified in the manifest record, and push them to a content publishing engine. Any content items that are not specified in the manifest record are rejected by the proxy. A processor of the content publishing engine can allow for continuous integration of the selected ones of the first content items into the specific release.

Abstract: A database system may determine that a database is unavailable to generate an identifier for an event or that events may not be written to the database. As a result, the database system may write the event to a low-latency, supplementary file system. The database system may determine that the database is available at a later time, and read the event from the supplementary file system, store the event in a memory component, and then delete the event from the supplementary file system. The database system may then access the database to generate an identifier for the event, write the event to the database, and then delete the event from the memory component.

Abstract: Disclosed are some examples of database systems, methods, and computer program products for processing log files. In some implementations, a server of a database system accesses a metadata file indicating algorithms that can be applied to data of log files. The server generates customer-facing log files using the log file and metadata file. The customer-facing log files include new data derived from using the algorithms and the data of the log files.

Abstract: Content deployment systems and methods are provided for integrating and deploying selected content items in a web content publishing process. A first content source can manage and store a plurality of first content items for potential inclusion in a specific release that is published as web content. Each content item can include one or more of: a set of directions for rendering web content and actual content that is rendered as web content. A content publishing module can store a manifest record that specifies release items that are allowed to be part of the specific release, and receive a content package object, from the first content source, that includes the first content items. It can then extract selected ones of first content items that are specified in the manifest record, and add them into a release object so that they are included as part of the specific release.

Abstract: Content deployment systems and methods are provided for integrating and deploying selected content items as part of a specific release. A content publishing engine includes a processor that can execute a release management API that is configured to manage and store a manifest record that specifies release items by API name that are allowed to be part of the specific release. The processor is configured to execute a bulk API that is configured to receive content package objects from a plurality of content sources. For example, the first content source can directly invoke the bulk API to send first content items to the content publishing engine. A filter module can extract selected first content items that are specified in the manifest record for inclusion in the specific release, and add the selected first content items into a release object so that they are included as part of the specific release.

Abstract: Content deployment systems and methods are provided for continuously integrating and deploying selected content items from a plurality of content sources into a specific release as part of the specific release. For example, a first content source stores a plurality of first content items for potential inclusion in the specific release. A manifest record for the specific release specifies release items, by API name, that are allowed to be part of the specific release. A proxy can periodically retrieve selected ones of the first content items that are specified in the manifest record, and push them to a bulk API of a content publishing engine. Any content items that are not specified in the manifest record are rejected by the proxy. A processor of the content publishing engine can allow for continuous integration of the selected ones of the first content items into the specific release.

Abstract: Content deployment systems and methods are provided for integrating and deploying selected content items as part of a specific release. A content publishing engine includes a processor that can execute a release management API that is configured to manage and store a manifest record that specifies release items by API name that are allowed to be part of the specific release. The processor is configured to execute a bulk API that is configured to receive content package objects from a plurality of content sources. For example, the first content source can directly invoke the bulk API to send first content items to the content publishing engine. A filter module can extract selected first content items that are specified in the manifest record for inclusion in the specific release, and add the selected first content items into a release object so that they are included as part of the specific release.

Abstract: Disclosed are some examples of database systems, methods, and computer program products for processing log files. In some implementations, log files can be accessed and identifiers can be generated for the data entries of the log files. The generated identifiers can be used to determine whether data entries in the log files are new, and therefore, should be extracted for analysis.

Abstract: Disclosed are examples of systems, apparatus, methods, and computer program products for validating educational content in an educational content management system. In some implementations, a validation rule can be generated. A first request to add first educational content to an educational content management system can be processed. A validation error associated with the first educational content can be identified using the validation rule. A first notification indicating the validation error can be provided to a user interface of a display device. A second request to add second educational content to the educational content management system can be processed. It can be determined that the second educational content satisfies the first validation rule. A second notification can be provided to the user interface of the display device indicating that the second educational content satisfies the first validation rule.

Abstract: Disclosed are some examples of database systems, methods, and computer program products for run-time schema for event records. In some implementations, event records satisfying a query can be identified. Attribute-value pairs of data of those identified event records can be stored in an unstructured data field of an event record.

Abstract: A database system may determine that a database is unavailable to generate an identifier for an event or that events may not be written to the database. As a result, the database system may write the event to a low-latency, supplementary file system. The database system may determine that the database is available at a later time, and read the event from the supplementary file system, store the event in a memory component, and then delete the event from the supplementary file system. The database system may then access the database to generate an identifier for the event, write the event to the database, and then delete the event from the memory component.

Abstract: A capture service running on an application server receives events from a client application running on an application server to be stored in a data store and stores the events in an in-memory bounded buffer on the application server, the in-memory bounded buffer comprising a plurality of single-threaded segments, the capture service to write events to each segment in parallel. The in-memory bounded buffer provides a notification to a buffer flush regulator when a number of events stored in the in-memory bounded buffer reaches a predefined limit. The in-memory bounded buffer receive a request to flush the events in the in-memory bounded buffer from a consumer executor service. The consumer executor service consumes the events in the in-memory bounded buffer using a dynamically sized thread pool of consumer threads to read the segments of the bounded buffer in parallel, wherein consuming the events comprises writing the events directly to the data store.

Abstract: Disclosed are some examples of database systems, methods, and computer program products for processing log files. In some implementations, log files can be accessed and identifiers can be generated for the data entries of the log files. The generated identifiers can be used to determine whether data entries in the log files are new, and therefore, should be extracted for analysis.

Abstract: Disclosed are some examples of database systems, methods, and computer program products for processing log files. In some implementations, a server of a database system accesses a metadata file indicating algorithms that can be applied to data of log files. The server generates customer-facing log files using the log file and metadata file. The customer-facing log files include new data derived from using the algorithms and the data of the log files.

Abstract: A capture service running on an application server receives events from a client application running on an application server to be stored in a data store and stores the events in an in-memory bounded buffer on the application server, the in-memory bounded buffer comprising a plurality of single-threaded segments, the capture service to write events to each segment in parallel. The in-memory bounded buffer provides a notification to a buffer flush regulator when a number of events stored in the in-memory bounded buffer reaches a predefined limit. The in-memory bounded buffer receive a request to flush the events in the in-memory bounded buffer from a consumer executor service. The consumer executor service consumes the events in the in-memory bounded buffer using a dynamically sized thread pool of consumer threads to read the segments of the bounded buffer in parallel, wherein consuming the events comprises writing the events directly to the data store.

Abstract: A capture service running on an application server receives events from a client application running on an application server to be stored in a data store and stores the events in an in-memory bounded buffer on the application server, the in-memory bounded buffer comprising a plurality of single-threaded segments, the capture service to write events to each segment in parallel. The in-memory bounded buffer provides a notification to a buffer flush regulator when a number of events stored in the in-memory bounded buffer reaches a predefined limit. The in-memory bounded buffer receive a request to flush the events in the in-memory bounded buffer from a consumer executor service. The consumer executor service consumes the events in the in-memory bounded buffer using a dynamically sized thread pool of consumer threads to read the segments of the bounded buffer in parallel, wherein consuming the events comprises writing the events directly to the data store.

Abstract: A capture service running on an application server receives events from a client application running on an application server to be stored in a data store and stores the events in an in-memory bounded buffer on the application server, the in-memory bounded buffer comprising a plurality of single-threaded segments, the capture service to write events to each segment in parallel. The in-memory bounded buffer provides a notification to a buffer flush regulator when a number of events stored in the in-memory bounded buffer reaches a predefined limit. The in-memory bounded buffer receive a request to flush the events in the in-memory bounded buffer from a consumer executor service. The consumer executor service consumes the events in the in-memory bounded buffer using a dynamically sized thread pool of consumer threads to read the segments of the bounded buffer in parallel, wherein consuming the events comprises writing the events directly to the data store.