I have been thinking some more and it looks like its a more general problem and not as easy a solution as it seems. If you think about it many bridges should not be analyzed (date, URL, class, numbers, enum etc: most of the built-in ones actually).
That being said a smart person might want to convert a class into its fqcn and then analyze that with a specific analyzer. Same for all the others. So making decisions is probably not a good idea after all :) On 20 mai 2010, at 20:04, Sanne Grinovero wrote: > Makes sense, maybe we could default to untokenized? Same idea should apply to > the soon-to-be-added NumericFields. > > >> Il giorno 20/mag/2010 14:58, "Emmanuel Bernard" <emman...@hibernate.org> ha >> scritto: >> >> Does it ever make sense to use @DateBridge without >> @Field(index=Index.UN_TOKENIZED) or NO_NORM >> >> I got caught up with doing >> >> @DateBridge(resolution=DAY) @Field >> public String getDate() { return date; } >> >> and having unexpected issues. >> >> If it never makes sense we could raise an exception when that happens, or >> simply force the index strategy to UN_TOKENIZE. >> >> WDYT? >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev