<div dir="ltr"><div class="gmail_default" style="font-size:small">There is an additional complex choice to make.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
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*?</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">!!! -><br></div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Does anyone see this as a strong limitation or usability concern?</div><div class="gmail_default" style="font-size:small">
This would also resolve a couple of performance problems.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Beyond this, considering it's valid (and sometimes useful) to store </div>
<div class="gmail_default" style="font-size:small"> </div><div class="gmail_default" style="font-size:small"> PersonFile p = ...</div><div class="gmail_default" style="font-size:small"> cache.put( p.taxcode, p );</div>
<div class="gmail_default" style="font-size:small"> cache.put( p.uniquename, p );</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.<br>
</div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small">Question remains if it's more correct to bind the index identification (the name) to the key type.</div><div class="gmail_default" style="font-size:small"><br></div>
<div class="gmail_default" style="font-size:small">
@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 :)</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small">Sanne</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 7 August 2014 22:50, Hardy Ferentschik <span dir="ltr"><<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 7 Jan 2014, at 23:42, Sanne Grinovero <<a href="mailto:sanne@hibernate.org">sanne@hibernate.org</a>> wrote:<br>
<br>
><br>
><br>
><br>
> On 7 August 2014 22:37, Hardy Ferentschik <<a href="mailto:hardy@hibernate.org">hardy@hibernate.org</a>> wrote:<br>
><br>
> On 7 Jan 2014, at 19:56, Sanne Grinovero <<a href="mailto:sanne@hibernate.org">sanne@hibernate.org</a>> wrote:<br>
><br>
> > I was hoping to drop @ProvidedId today as the original "marker"<br>
> > functionality is no longer needed: since we have<br>
> ><br>
> > org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()<br>
> ><br>
> > the option can be implicitly applied to all indexed entries, and the<br>
> > annotation is mostly redundant in Infinispan since we added this.<br>
> ><br>
> > But actually it turns out it's a bit more complex as it servers a second<br>
> > function as well: it's the only way for users to be able to specify a<br>
> > FieldBridge for the ID.. so the functionality of this annotation is not<br>
> > consumed yet.<br>
><br>
> Wouldn’t an additional explicit @FieldBridge annotation work as well?<br>
><br>
> Yes! But we'd need to apply it to the key type.<br>
> 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.<br>
<br>
</div></div>Fair enough. I also know too little about the Infinispan usage of Search in this case.<br>
Either way, @ProvidedId should go, at least from a pure Search point of view.<br>
<span class="HOEnZb"><font color="#888888"><br>
—Hardy<br>
<br>
</font></span></blockquote></div><br></div>