1. in the case of object fields:

@IndexedEmbedded

Maybe we just say - provide another binder for it, i.e.:

The problem with this, is that property binders are intrinsically related to the concept of “property” on the java side – and we have none of that here.

Type binders could work, but I’m not sure it’s a great idea.

could definitely help in this area though.

but I’m unsure if EL can evaluate multiple lines… which made me think about JSR223 (we have that in the validator). That one would allow having some script and access/modify the objects we pass to the script…

As far as I’m concerned, anything works, as long as it can run in the annotation processor, is relatively standard, doesn’t imply problematic dependencies, and doesn’t require configuration outside of annotations.

3. We can probably reuse this idea of dynamic mapping to address the case with the number of fields that depend on some parameter…

I’d personally rather leverage Optional<> + @DynamicReferences("enable = true") or something similar, rather than introduce DynamicIndexFieldReferenceContainer, because that would prevent us from inferring the Java type of fields.

But yes, @DynamicReferences can probably help here.

I think so, yes. In the validator processor that’s what we do, check the constraints and report the line in the source file where the constraint is applied incorrectly.

Sounds awesome

This looks interesting. Here are a few questions/thoughts I got while going through it:

1. in the case of object fields:

Maybe we just say - provide another binder for it, i.e.:

2. For the dynamic mapping, this looks interesting:

but I’m unsure if EL can evaluate multiple lines… which made me think about JSR223 (we have that in the validator). That one would allow having some script and access/modify the objects we pass to the script…

3. We can probably reuse this idea of dynamic mapping to address the case with the number of fields that depend on some parameter…

But then I’m unsure about adding a dependency either on EL or Groovy…

would probably be able to report such errors in the exact place in the code where they happen.

I think so, yes. In the validator processor that’s what we do, check the constraints and report the line in the source file where the constraint is applied incorrectly.

One idea I had last night, please tell me what you think …

For binders, we could rely on “injection” of field definitions, defined through annotations.

For example:

Interestingly, the syntax would allow setting a value binder or value bridge within a property binder… so maybe we should just drop the concept of dslConverter/projectionConverter from this API, and rely on value bridges instead. This would significantly simplify both generic types (no need to specify the underlying field type) and bind method (no need to set the dslConverter/projectionConverter), and would finally allow composition of bridges in Hibernate Search:

Incidentally, this would also allow relying on default bridges in property binders, something that’s very handy for enums!

Object fields, however, will need some more thought, because we need to specify which “value field” goes into which object field.

may be play a role here… but maybe we could just rely on @IndexedEmbedded and some composition?

Now, this is all static… which is quite limiting. You can’t make a binder adapt to parameters to change the field types, for instance.

… or can you? If we introduced dedicated annotation leveraging an expression language, would that work?

We could have one EL-based annotation per mapping annotation:

… but that’s not very practical when one wants to mix static and dynamic config, and it’s arguably a lot of annotations to add.

So instead, we could use a generic-purpose annotation (probably cleaner, but less obvious) that could be applied on top of the mapping annotation:

Note that while EL is technically a dynamic language with the downsides that implies (runtime errors), when people use the annotation processor we’d catch an error at compile time, and would probably be able to report such errors in the exact place in the code where they happen. So, dynamic, but not so bad.