See [HSEARCH-4386] : the current syntax using {{@ObjectPath}}/{{@PropertyValue}} is far from clear and can lead to mistakes that yield confusing error messages.
To prevent that kind of mistake in the first place, we could provide (and recommend) a more straightforward way to provide paths.
h4. Solution 1: simply allow string representations
Minimal changes; just allow passing paths as strings:
{code:java}@IndexingDependency(derivedFrom = { @ObjectPath(asStringfromString = "firstName"), @ObjectPath(asStringfromString = "familyName") }){code}
Such a syntax would need to handle references to value extractors too, however; maybe we'll pick the current syntax "foo<collection>.bar", or maybe we'll switch to something better.
h4. Solution 2: string representations + new annotations with better names/structure
Do the above, but *also* rethink the name and structure of the {{@IndexingDependency}}/{{@AssociationInverseSide}}/{{@ObjectPath}}/{{@PropertyValue}} annotations so that it's impossible to think "ah, {{@ObjectPath(value = ...)}} probably allows me to provide multiple paths".
This is easier said than done, though...
When thinking about this, we should probably take into account the changes suggested in [HSEARCH-4271] too. |
|