5:40 p.m.
There is an additional complex choice to make.
Considering that Infinispan has this separate notion of Key vs Value, and
both have to contribute to building the final indexed Document, why is it
that we allow the decision of which index is being targeted to be made by
*the type of the value*?
I think the index definition belongs as a responsibility to the *type of
the identifier*, the value should at most help to identify a shard among
the ones identified by its key.
!!! ->
We might want to consider imposing a hard limitation of not allowing a
single index to be shared across multiple key types. This implies the
@Indexed annotation and its other key options should be defined on the
keys, not the values.
If we did that, it wouldn't matter if the index is defined on the key or on
the value as there would be a 1:1 possible combination.
Does anyone see this as a strong limitation or usability concern?
This would also resolve a couple of performance problems.
Beyond this, considering it's valid (and sometimes useful) to store
PersonFile p = ...
cache.put( p.taxcode, p );
cache.put( p.uniquename, p );
As a user I think I might even want to define an alternative index mapping
for PersonFile, depending on if it's being stored by uniquename or by
taxcode.
That's totally doable with the Search engine, but how do you envision the
user to define this mapping? He can't use annotations on PersonFile, so the
user needs to be able to register some form of programmatic mapping linked
to the different key types.
There is an additional flaw, which is that I'm implying that taxcode and
uniquname are of a different type: otherwise we couldn't distinguish the
two different meanings of the two put operations. This is generally a fair
assumption as you wouldn't want to have key collisions if you're storing in
such a fashion, but there might be a known business rule for which such a
collision is impossible (i.e. the two codes having a different format). So
while you probably shouldn't do this in a strong domain, it's a legal usage
of the Cache API.
Considering these pitfalls I think I have successfully convinced myself
that we should not allow for a different mapping for the same type of key.
Question remains if it's more correct to bind the index identification (the
name) to the key type.
@Hardy yes I will need the Infinispan team's thoughts too, but don't feel
excluded, there aren't many smart engineers around knowing about the
Infinispan/Query usage :)
Cheers,
Sanne
On 7 August 2014 22:50, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 7 Jan 2014, at 23:42, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
>
>
> On 7 August 2014 22:37, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>
> On 7 Jan 2014, at 19:56, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
> > I was hoping to drop @ProvidedId today as the original "marker"
> > functionality is no longer needed: since we have
> >
> >
org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()
> >
> > the option can be implicitly applied to all indexed entries, and the
> > annotation is mostly redundant in Infinispan since we added this.
> >
> > But actually it turns out it's a bit more complex as it servers a
second
> > function as well: it's the only way for users to be able to specify a
> > FieldBridge for the ID.. so the functionality of this annotation is not
> > consumed yet.
>
> Wouldn’t an additional explicit @FieldBridge annotation work as well?
>
> Yes! But we'd need to apply it to the key type.
> This implies changing it to allow target @Target(TYPE), which doesn't
make much sense for our ORM users, but also the name "FieldBridge" is
rather odd to be applied on a type and not a field.
Fair enough. I also know too little about the Infinispan usage of Search
in this case.
Either way, @ProvidedId should go, at least from a pure Search point of
view.
—Hardy