Answers inline
On Thu, 11 Aug 2011 14:27:58 +0200, Sanne Grinovero <sanne(a)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