Elide 6 documentation can be found here. Elide 4 documentation can be found here.
Elide 5 introduces several new features:
The analytics capabilities, asynchronous API, and table export API were developed in conjunction with a powerful Analytics UI called Yavin.
The only notable API change are:
In addition to new features, Elide 5 streamlines a number of public interfaces to simplify concepts. This includes:
Check class hierarchy.NonTransferable permission (which replaces SharePermission).User abstraction for authentication.DataStoreTransaction interface.FilterDialect interface.Include annotation now defaults to marking models as root level. The ‘type’ attribute was renamed to ‘name’.Include annotation at the package level now denotes a namespace. The ‘name’ attribute will be prepended to all elide models contained therein.Because Elide 5 is a major release, we took time to reorganize the module & package structure including:
Elide no longer has separate classes (InlineCheck & CommitCheck) that determine when a check runs (immediately before a field is read/written or immediately before transaction commit). Instead, all checks (regardless of type) run immediately before a field is read/written except for checks on newly created objects (which run at transaction commit). However, there is a method in Check that can force Elide to run the check at transaction commit preserving the legacy behavior. The new class hierarchy looks like this:
Filter expression checks now take a Type instead of a Class when referring to the Elide model:
public abstract FilterExpression getFilterExpression(Type<?> entityClass, RequestScope requestScope);
See Elide’s security documentation for details on how to define checks.
Prior to Elide 5, models were unshareable by default and had to be annotated with SharePermission to share them with other collections after creation. In Elide 5, the default state is inverted. All models are shareable by default and must be explicitly marked NonTransferable to limit collection assignment after creation.
Similar to Elide 4:
NonTransferable annotation.Elide’s User abstraction has four new changes:
User explicitly wraps a java.security.Principal object rather than a java.lang.Object.User includes methods to get the identity/name of the underlying principal as well as any role memberships the principal has.SecurityContext to an underlying principal object.AuthenticationUser) which wraps a Spring org.springframework.security.core.Authentication object.SecurityContextUser) which wraps a javax.ws.rs.core.SecurityContext object.Security checks which dereference the User object will require changes to access the underlying principal object depending on the framework they use.
All methods which load objects from persistence now are passed an EntityProjection rather than a Class. The projection has more information to help the DataStore optimize its loads including:
The transaction getRelation method now takes a Relationship object instead of a Class. The relationship is essentially a named EntityProjection.
The transaction getAttribute and setAttribute functions now take Attribute objects - a shared concept with the new EntityProjection.
The DataStoreTransaction no longer requires a method to access the User object during transaction initialization.
Nearly every method now takes a RequestScope object.
The methods supportsFiltering, supportPagination, and supportSorting include additional information to help data stores make more informed decisions.
All methods that referred to models as Objects now leverage Java generics instead.
The life cycle hook function now includes extra parameters to indicate what operation is being performed on the model and when in the transaction lifecycle it occurred:
public abstract void execute(LifeCycleHookBinding.Operation operation,
LifeCycleHookBinding.TransactionPhase phase,
T elideEntity,
RequestScope requestScope,
Optional<ChangeSpec> changes);
To register life cycle hooks, all the prior annotations can be replaced with a single annotation. The hook logic now should reside outside the Elide model classes. However, legacy life cycle hook annotations remain supported.
The following classes/interfaces have been refactored to limit exposure to only the public contract:
To accomplish this, elide-core and elide-annotations had to be consolidated into a single artifact.
Elide 5 fixes a number of problems with error reporting:
The interface to override a JPQL predicate for a filter operator has new, richer contract:
@FunctionalInterface
public interface JPQLPredicateGenerator {
String generate(FilterPredicate predicate, Function<Path, String> aliasGenerator);
}
Elide models are no longer static JVM classes but instead leverage Elide’s new Type system. This change allows data stores to register models that are not static classes.
It is possible to convert between a Class and Type and vice versa. An Elide model class can be converted to a Type by wrapping it in a ClassType:
new ClassType(Book.class)
A Type can be converted to a model class by calling the following method:
Optional<Class<T>> getUnderlyingClass();
The type of any model instance can be returned by calling the following static method on the EntityDictionary:
public static <T> Type<T> getType(T object);