On Thu, 11 Aug 2011 13:51:33 +0200, Sanne Grinovero <sa...@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. > 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? > 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? --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
