We want to make it as easy as possible for users to switch between indexing services (Lucene, Elasticsearch).

To that end, we would isolate as much as possible the mapping from the indexing services specifics.
This means in particular that field bridges would no longer give access to Lucene-specific features (such as SortedDocValuesFields), but would only serve the purpose of transforming the data from the entity model to a generic document model. Then we'd have another layer (maybe customizable) that would transform the data from the generic document model to a document model that would be specific to an indexing

So we'd have:

Entity ====[Field bridge]===> Generic Document ====[Indexing service specific bridge]===> Indexing service specific document

Note that the indexing service specific bridge might only be a standard, non-customizable singleton (on contrary to field bridges): this is yet to be determined.

We'd likely require a reverse process when extracting query results:

Entity <====[Field bridge]=== Generic Document <====[Indexing service specific bridge]=== Indexing service specific document

See HSEARCH-2055 Open for discussions about this "FieldBridge 2.0" API.

The purpose of this ticket is to discuss required changes to the metadata. Indeed, to support this process, we'd need metadata about the generic document model: which fields are supposed to be sortable, what are their types, their expected formats (for dates in particular), etc., so that the indexing service specific bridge would know how to interpret the generic document.
Before starting the actual work, we'll probably need to enumerate the required metadata.