Answers inline On Thu, 11 Aug 2011 14:27:58 +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. > > 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
