| It's most obvious for extractors:
@GenericField(extractors = {
@ContainerValueExtractorBeanReference(type = MapValueExtractorImpl.class),
@ContainerValueExtractorBeanReference(type = IterableElementExtractorImpl.class)
})
It's awfully verbose, and a bit confusing too, since it looks like we're using internal types from Hibernate Search. We could remove the intermediary @ annotation:
@GenericField(extractors = {MapValueExtractorImpl.class, IterableElementExtractorImpl.class})
... but then we wouldn't be able to (later) add a way for users to refer to a container value extractor by its name. Maybe we could expect the references to container value extractors to be strings only?
Something like this:
@GenericField(extractors = {BuiltinExtractors.MAP_VALUE, BuiltinExtractors.ITERABLE})
That would, however, require us to provide some way for users to register their custom container value extractors. Ideally we should use a dedicated reference type, but we can't use enums because we expect users to write their own extractors, and we can't use a dedicated interface because that's not allowed in annotations. Maybe we could shorten the name of the "container value extractor reference" annotation (we'd have to do the same for other "reference" annotations), and allow to use either enums for built-in types, or class/string for custom types. Something like this:
enum BuiltinExtractors {
AUTOMATIC, ITERABLE,
COLLECTION,
MAP_VALUES,
MAP_KEYS,
...
}
@GenericField(extractors = {
@ContainerExtractor(BuiltinExtractors.MAP_VALUES), @ContainerExtractor(BuiltinExtractors.ITERABLE),
@ContainerExtractor(type = MyCustomExtractorType.class),
@ContainerExtractor(name = "myOtherCustomExtractorType"),
})
And for value bridges:
enum BuiltinValueBridges {
AUTOMATIC, INTEGER,
LONG,
STRING_KEYWORD,
DATE,
LOCAL_DATE,
LOCAL_DATE_TIME,
...
}
@GenericField(bridge = @ValueBridge(BuiltinValueBridges.DATE)) @GenericField(bridge = @ValueBridge(type = MyCustomValueBridge.class))
@GenericField(bridge = @ValueBridge(name = "myOtherCustomValueBridge"))
|
