Version 3 of querysearch is in itself not a major functional upgrade, but it is the first version with its model infrastructure depending directly on its ontology model rather than the old elements-based metamodel. This means that it is expanded using the ontology expanders.
The querysearch-builders module no longer exists. If it is used in an expanders project, remove the dependency. The
builders are now part of the querysearch-core module.
The QueryValueType enumeration is used to indicate the type of an object passed to a query constraint. Usually a
developer will not interact with this, as every constraint factory method that takes it as a parameter, also comes with
a variant that does not. In the latter case, the type will be inferred from the object that is passed to the constraint.
This can only be inferred for known types, which is mostly primitives and java.util.Date.
As a default, when not recognized, the type would automatically be set to String, resulting into a conversion of the
object to String in supporting constraints. With this update the type QueryValueType.OBJECT was added which handles
the supplied object as a raw value that is passed directly into JPA, as this is sometimes desired.
Since converting to String is typically not intended behavior for objects that are not of that type, the default when a
type cannot be determined is now QueryValueType.OBJECT. This is a breaking change, but should have very little impact,
as currently, cases where unknown object types are passed to a constraint are likely to be unintended. In cases where
this is intended, the migration guide will explain how to resolve this in the new
implementation.
The when(boolean, QueryConstraint) and whenOrElse(boolean, QueryConstraint) methods have been removed after being marked as deprecated for three years. These methods were fundamentally flawed as the constraints are passed as a parameter adn as such evaluated immediately, instead of only when the condition is true as per the design of these constraints.
The exists(qualifiedElementName, variableName, constraint, queryOptions) constraint method has now been marked as deprecated. This method was superseded by a new exists() method in version 1.7.0, which takes a QueryBuilder instance as an argument. Using the QueryBuilder instance if more version transparent and more readable.
The QuerySearchOptionType element has been removed in favor of using the new ValueType system introduced in the elements metamodel. This change aligns the querySearch metamodel more with the elements model which it extend and will allow for more flexibility as the metamodel is refined further.
This change was also planned for quite a long time ago and the reason the model was still considered unstable. With this change now implemented, the querySearch metamodel can now be considered to be stable and will no longer be subjected to large breaking changes in the future.
Following changes to NS model infrastructure, which now introduces options for every DataElement, the QuerySearchOption and QuerySearchOptionType elements have been removed. This functionality has so far not been adopted in such a way that it would have an impact. The new Option and OptionType elements in prime-core are now used as an alternative.
Though still under development and prone to changes, this version introduces a very large structural change in the meta-model for QuerySearch, which may affect other expansion resources and early adopters.
The QuerySearch element now has DataElement as its parent element, rather than Component like it did before. This is the correct intended structure for the model, which was previously not possible due to technical limitations. What this affects:
QuerySearch.component field no longer exists and is now only accessible as QuerySearch.dataElement.component.QuerySearch instances are now registered in DataElement.extensions[] instead of Component.extensions[].QuerySearch model xml files have moved from <componentRoot>/model/querySearchs to <componentRoot>/model/dataElements/<dataElement>/querySearchs.QuerySearch model files should no longer contain a DataRef to the parent DataElement.The QuerySearchResolver class was moved from the data layer to the logic layer. Since this is used most commonly to resolve references to other components, the use of Cruds classes in the data layer will create high coupling between those components, which is not intended.
To transition to the logic layer implementation, the Agent classes should be used when resolving data for elements in other components. In this scenario there is also no need to use dependency injection with EJB, as the agents do not require this.
A transient option querysearch.transient.dataLayerResolver.enable has been supplied to revert the behavior of the expanders for backwards compatibility. But keep in mind that this option will be removed in the future and has only been supplied for short-term compatibility if needed, allowing for planning to upgrade the codebase. This option will once again expand the QuerySearchResolver in the data layer, rather than the logic layer.