In The idea is to add support for all types that were supported in Search 5.
You can find the types supported in Search 5 by having a look at implementations of {{org.hibernate.search. v6poc bridge . backend spi . document BridgeProvider}} . model This should essentially include all primary types, java . IndexSchemaFieldContext util.Date, java.util.Calendar, the java.time types, the numeric types (Short, Double, Float, ...), BigDecimal and BigInteger, and maybe more.
Only the boxed versions of types ({{Integer }} , not {{int}}) actually require code in the backend to support them, the others should be supported automatically thanks to existing code in the mapper .
See in Search 5 The code changed a bit since HSEARCH-3265, but on a higher level the list of tasks will be fairly similar.
For each type, we need to :
* NumericBridgeProvider Implement the backend support:
* JavaTimeBridgeProvider
* BasicJDKTypesBridgeProvider
Do not forget Add a {{asMyType()}} method in the field type definition API, and the appropriate implementation in each backend (Lucene + ES). Please look at existing implementations for similar types first, you may be able to change reuse code. In particular in the Lucene backend, there is a common pattern for all numeric types.
** Update the implementations of the {{ as(Class<?>)}} method in the same interface to support the new type
** Add integration tests to the backend TCK. This mainly means implementing a {{ org.hibernate.search. v6poc integrationtest .backend. document tck . model testsupport . IndexSchemaFieldContext types.FieldTypeDescriptor}} and referencing your implementation from {{org.hibernate.search.integrationtest.backend.tck.testsupport.types.FieldTypeDescriptor # as getAll }} . See {{org.hibernate.search.integrationtest.backend.tck.testsupport.types.LongFieldTypeDescriptor}} for an example. After you implemented that, run {{org.hibernate.search.integrationtest.backend.tck.search.predicate.MatchSearchPredicateIT#match}} and check that your type appears in the list of tests.
* Implement the mapper support
** Register a default value bridge for the type in {{org.hibernate.search.mapper.pojo.bridge.impl.BridgeResolver#BridgeResolver}}. Generally a {{PassThroughValueBridge}} should be enough, but in some cases you may want to add a specific implementation (java.util.Calendar in particular, see below).
** Where that makes sense (= the type could reasonably be used as appropriate an entity ID), register a default identifier bridge for the type in {{org .
hibernate.search.mapper.pojo.bridge.impl.BridgeResolver#BridgeResolver}}.
** Add integration tests to the pojo mapper ITs. This mainly means implementing a {{org.hibernate.search.integrationtest.mapper.pojo.testsupport.types.PropertyTypeDescriptor}} and referencing your implementation from {{org.hibernate.search.integrationtest.mapper.pojo.testsupport.types.PropertyTypeDescriptor#getAll}}. See {{org.hibernate.search.integrationtest.mapper.pojo.testsupport.types.BoxedLongPropertyTypeDescriptor}} for an example. After you implemented that, run {{org.hibernate.search.integrationtest.mapper.pojo.mapping.definition.FieldDefaultBridgeIT}} and check that your type appears in the list of tests.
*** Note that for boxed/primitive types ({{Short}}/{{short}}) *you need an implementation for both the boxed type and the primitive type*.
Note there are particular cases: Calendar in particular doesn't need to be implemented in the backend; converting it to a ZonedDateTime should be enough. So you will only need to implement a bridge in the mapper similar to {{org.hibernate.search.mapper.pojo.bridge.builtin.impl.DefaultJavaUtilDateValueBridge}}, reference it from the bridge resolver and add mapper tests: nothing to do on the backend side.
As to the commits, I would recommend to not be more precise than, for each type one commit for the backend impls (both ES + Lucene), one for the backend tests, one for the mapper impl, one for the mapper tests. And I think you can safely squash that into just two commits, one for the backends and one for the mapper. |
|
