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

Reply via email to