Version 1.9.4

• Fixed a bug that occurred when using pre-select to load a Record containing a reference field whose declared type is the parent class of a descendant class with additionally defined fields and the stored value for that field is an instance of that descendant class. In this case, the pre-select logic did not load data for the descendant defined fields, which resulted in unexpected NullPointerException regressions or an overall inability to load those Records if the descendant defined field was annotated as Required.
• Improved the efficiency of local condition evaluation by removing unnecessary data copying.
• Addressed performance regressions that have been observed when performing pagination alongside a locally resolvable filter or condition whose matches are sparsely distributed among the unfiltered results. The pagination logic still incrementally loads possible matches (instead of all-at-once), but uses additional logic to dynamically adjust the number of possible matches loaded based on whether the previous batch contained any matches.

Version 1.9.3

• For instances of Concourse Server at version 0.11.3) or greater, we improved overall read performance by pre-selecting data for linked Records, whenever possible. Previously, if a Record contained an attribute whose type was another Record, Runway would eagerly load the data for that reference in a separate database call. So, if Runway needed to process a read of many Records with references to other Records, performance was poor because there were too many database round trips required. Now, Runway will detect when a Record has references to other Records and will pre-select the data for those references while selecting the data for the parent Record if it is possible to do so. This greatly reduces the number of database round trips which drastically improves performance by up to 89.7%.
  • This improvement is automatically enabled whenever Runway is connected to a Concourse deployment at version [0.11.3+]. If necessary, it is possible to disable the functionality when building a Runway instance by invoking the disablePreSelectLinkedRecords() method.
• Added a new Runway.properties() method that exposes an interface to get metadata and other information about a Runway instance. This interface can be used to query whether a Runway is capable and configured to take advantage of pre-selection.
• Improved the performance of Runway commands that perform pagination when a filter or a condition that must be resolved locally (e.g., because it references derived or computed keys not in the database) is provided. Previously, in these cases, Runway would load all possible records before applying the filter or condition and lastly performing pagination. Now, Runway incrementally loads possible matching records and applies the filter or condition on the fly until the requested Page has been filled.
• Removed the com.cinchapi.runway.util.Paging class that was copied from the concourse-server project since it is no longer used for internal pagination logic.
• Removed unnecessary random result set access when lazily instantiating the Set of records that match a Runway operation.
• Optimized load performance by
  • using more intelligent logic to scaffold a Record instance and
  • performing static analysis and caching immutable metadata for Record types that was previously computed during each load.

Version 1.9.2

• Upgraded the underlying Concourse client dependency to version 0.11.2, which means that Runway now supports specifying a CCL function statement as an operation key or an operation value if it is connected to a Concourse Server that is version 0.11.0+.

Version 1.9.1

• Fixed a bug that randomly causes a spurious error to be thrown indicating that a Record attribute doesn't exist in the database when an attempt is made to access it.

Version 1.9.0

• Added support for multi-field Unique value constraints. When applying the Unique constraint to a Record field, you can now provide a name parameter (e.g. @Unique(name = "identity")). If multiple Unique annotated fields have the same name, Runway will enforce uniqueness among the combination of values for all those fields across all Records in the same class. If a Unique annotated field is a Sequence, Runway will consider uniqueness to be violated if and only if any items in the sequence are shared and all the other fields in the same uniqueness group are also considered shared.
• Added Realms to virtually segregate records within the same environment into distinct groups. A Record can be dynamically added to or removed from a realm (use Record#addRealm and Record#removeRealm to manage). Runway provides overloaded read methods that accept a Realms parameter to specify the realms from which data can be read. If a Record exists in at least one of the specified Realms, it will be read.
  • By default, all Records exist in ALL realms, so this feature is backwards compatible.
  • By default, read methods consider data from ANY realm, so this feature is backwards compatible.
• Fixed a bug where the Required annotation was not enforced when loading data from the database. If a record was modified outside of Runway such that a required field was nullified, Runway would previously load the record without enforcing the constraint. This caused applications to encounter some unexpected NullPointerExceptions.

Version 1.8.1

• Fixed a bug that allowed for dynamically seting an intrinsic attribute of a Record with a value of an invalid type. In this scenario, Runway should have thrown an error, but it didn't. While the value with the invalid type was not persisted when saving the Record, it was return on intermediate reads of the Record.

Version 1.8.0

• Improved validation exception messages by including the class name of the Record that fails to validate.
• Added a onLoadFailure hook to the Runway.builder that can be used to get insight and perform processing on errors that occur when loading records from the database. Depending on the error, load failures can be fatal (e.g. the entire load operation fails). The onLoadFailure hook does not change this, but it does ensure that fatal errors can be caught and inspected. By default, Runway uses a non-operational onLoadFailure hook. The hook can be customized by providing a TriConsumer accepting three inputs: the record's Class and id and the Throwable that represents the error.
• Fixed an issue that occurred when setting a value to null and that value not being removed from the database.

Version 1.7.0

• Fixed a bug that caused Runway to exhibit poor performance when using the withCache option.
• Fixed bugs that caused Runway's data caching to exhibit inconsistent behaviour where stale data could be added to the cache.
• Added a Runway#builder option to specify a readStrategy. Runway's read strategy determines how Runway reads data from Concourse.
  • The BULK strategy uses Concourse's select method to pull in all the data for all the records that match a read at the same time.
  • The STREAM option uses Concourse's find method to find the ids of all the records that match a read in order to stream the data for those records on-the-fly when needed.
  • The AUTO option contextually uses the BULK or STREAM option on a read-by-read basis (usually depending on which option will return results faster).
    By default, Runway uses the AUTO strategy unless a cache is provided, in which case, the STREAM option is used by default since data streaming is more cache-friendly and is consistent with the way record caching previously worked in previous versions of Runway.
• Deprecated the recordsPerSelectBufferSize option in the Runway#builder in favor of the streamingReadBufferSize option which has the same effect.

Version 1.6.0

• Fixed a bug that caused Runway operations to occassionally trigger an out of sequence response error in the underlying Concourse connections.
• Added support data caching. This feature can be enabled by passing a Cache to the Runway#builder#withCache method. Data caching is an improvement over record caching. With this new feature, caching is managed closer to the level of database interaction to ensure greater performance, timely invalidation and scalability.
• Improved internal logic that determines whether Runway serves a request by bulk selecting data or incrementally streaming.
• Added initial support for finding and counting Criteria conditions that touch computed and derived data. There is currently no support for querying on non-intrinsic data of linked Records (e.g. no navigation).

Version 1.5.0

• Fixed a bug that caused the countAny methods to return the wrong data.
• Added methods to the Runway driver that support filtering data. Unlike a Criteria or Condition a filter is a Predicate that receives the loaded Record as input and executes business logic to determine whether the Record should be included in the result set. For example, filtering can be used to seamlessly enforce permissions in a Runway method call by passing in a predicate that checks whether the caller has access to the Record.
• Remove support for record caching. The Runway#builder#cache method has been deprecated. Providing a record cache to Runway no longer has any effect.
• Added an onLoad hook to the Record class that can be used to provide a routine that is executed whenever an existing Record is loaded from the database.
• Fixed a bug that caused the linked objects included in the map or json functions to not respect the provided SerializationOptions.