Feature Request: Extended Field Type Support in Jmix Search @AutoMappedField

Support
,
#1

Hi Jmix Team,

First of all, thank you for the incredible work on
the Jmix framework. We truly appreciate the effort
and dedication that goes into making it such a
powerful and developer-friendly platform!

We are currently implementing Jmix Search with
OpenSearch in our project and have been really
impressed with the search capabilities. However,
we have encountered a couple of limitations that
we would like to humbly bring to your attention.

We hope these can be considered for a future release.

─────────────────────────────────────────────────

  1. Support for Date, Boolean and Numeric Field Types
    ─────────────────────────────────────────────────

We noticed that @AutoMappedField currently supports
only String-based fields for indexing. Other field
types are silently ignored:

@AutoMappedField(includeProperties = {
“startDate”, // LocalDate - not indexed
“isArchive”, // Boolean - not indexed
“contractValue” // Double - not indexed
})

Since OpenSearch natively supports date, boolean and
numeric field types, we believe exposing these through
a stable public API would greatly enhance the search
capabilities available to developers.

We did explore @ManualMappingDefinition as a potential
workaround. However, we noticed that Jmix itself flags
AutoMappingStrategy and SimplePropertyValueExtractor
as internal API with the following warning:

“Usage of this element in the application code is
not recommended. It’s a part of internal API and
may be changed or removed in the future.”

Given this warning, we are hesitant to use it in
production code as it may break in future upgrades.

─────────────────────────────────────────────────
2. Dynamic Attributes Support in Search
─────────────────────────────────────────────────

We also explored indexing Dynamic Attributes and
discovered that only String/text type Dynamic
Attributes are currently indexed. All other types
appear to be silently ignored:

  • Date Dynamic Attribute - not indexed
  • Boolean Dynamic Attribute - not indexed
  • Numeric Dynamic Attribute - not indexed
  • Entity Dynamic Attribute - not indexed

Note: We tested this behavior on the Jmix snapshot
version as well and the same limitation exists.

We would greatly appreciate any guidance on the
recommended approach for indexing Dynamic Attributes
and whether support for non-text Dynamic Attribute
types is planned for a future release.

─────────────────────────────────────────────────
Summary of Requested Enhancements
─────────────────────────────────────────────────

:white_check_mark: LocalDate / OffsetDateTime → date type
:white_check_mark: Boolean → boolean type
:white_check_mark: Double / Integer → numeric type
:white_check_mark: Dynamic Attributes → full type support

Environment:

  • Jmix Version : 2.7
  • Search Add-on : jmix-search-opensearch-starter
  • Search Engine : OpenSearch

We completely understand if these enhancements are
not immediately feasible and are happy to work with
any interim guidance or workarounds the team may
suggest.

Once again, thank you so much for your continued
support and for building such a wonderful framework.
We look forward to hearing your thoughts!

Warm regards,
Naveen

1 Like
#3

Hi,

Datatypes

Search was initially focused on textual data.
We have plans to add out-of-the-box support for some non-textual data but I can’t give an exact timeline.

@ManualMappingDefinition is a good way to implement something extra on the project side. Basically you can implement whatever logic you want including mapping non-textual data. It was designed to allow to customize as much as possible. You can implement your own Value extractors, Field mappers or entire Strategy.

About “internal API” - you are right it doesn’t look like those classes (which can be used within manual mapping) should be marked as “internal”.
This will be addressed in the near future.
As a possible outcome of that - they can change their packages. Doesn’t expect chahges in API.

Dynamic attributes.

In terms of “scalar” attributes they follow the same rules as the regular ones. So when we add OOB support for the new data types it should work for both.

Entity (reference) dynamic attribute has additional limitation comes from Dynamic Attributes itself. We will see what we can do but can’t provide any dates.

Thanks for your feedback.

Regards,
Ivan