[hibernate-dev] [Search] Sharding configured on types, not on indexes

[Hardy Ferentschik]

Answers inline

On Thu, 11 Aug 2011 14:27:58 +0200, Sanne Grinovero <sanne at hibernate.org>  
wrote:

>>> This also means we could change the sharding strategy interface to:
>>>  a - deal with Entity instances instead of org.apache.lucene.Document
>>> and string-encoded ids
>>
>> Are there not valid use-cases where I want to make the decision using  
>> the
>> Document. What if I have a custom class bridge which I apply on all
>> entities
>> in order to add a field to the document ((partly)independent of the  
>> entity
>> itself)
>> which is then used for sharding. I guess I could always write the same
>> logic
>> in the ShardingStrategy!? Not sure.
>
> I've thought about that same, and concluded than since the Document is
> the output of some stateless transformation from the entity, I'm sure
> that all what you could do in a custom bridge & sharding strategy
> could be implemented in the sharding strategy alone, provided it gets
> access to the entity. By definition the entity has more information,
> not less, so it's definitely an added value.
> Also if you had to change both code places to achieve your desired
> sharding strategy, now you only need to do it once, in something
> properly named "ShardingStrategy", instead of hacking around and
> possibly instead of inserting extra unneeded tokens in the Document
> for consumption of the ShardingStrategy.

I agree. If you pass along the entity you are always do the same
transformations/decisions, but do you need to do it again if you already  
applied
the logic in the bridge (provided you want the information indexed as well)

>>> This would affect configuration: instead of configuring them on the
>>> index name, an annotation should be placed on the type (or an optional
>>> parameter for existing @Indexed).
>>
>> Are changing the sharding configuration and the ShardingStrategy really
>> coupled? We could change the way shards are configured and still keep
>> passing the Document to the sharding strategy, maybe in combination with
>> the actual entity. Wouldn't that give most flexibility?
>
> As above, I don't think that will give you more functional options,
> but maybe you're right that some operations might be easier: I'm
> thinking of those cases in which the decisions is related to the
> string-encoded form of some complex type,

That's what I am thinking about as well.

>>> On top of a greater flexibility in sharding, but will also avoid
>>> exposing the o.a.l.Document yet in another API.
>>
>> Is that such a bad thing?

> Not extremely evil, but I hope above answers this.

I am not too concerned about exposing the Document, but overall don't have  
a strong
argument against your suggestion. Just wanted to share my initial thoughts  
and
concerns.

--Hardy