Hi Sanne,
> Proposal for next versions: allow @Stereotype - like user annotations?
> We would let the user define custom annotations to stack/combine
> multiple framework annotations, possibly centralizing what the
> "default" is for your app and reduce the amount of code people have to
> pile on
Hi Hardy,
> It depends. Maybe you want to boost any of these fields ad index time.
OK, what about the document id? It is indexed with NOT_ANALYZED_NO_NORMS.
As far as I understand (please correct me if I'm wrong) to boost fields at
index time
norms must be enabled for those fields. And because H
Hi Hardy,
> I am not quite sure which message we are talking about concretely, but I just
> wanted to say that you
> can configure the log level for each single class. You don't have to provide
> a custom implementation
> just because you don't like the logging in the default implementation.
Hi Sanne,
>> Our custom implementation is based on TransactionalWorker. We have a
>> requirement
>> to specify the index base by a system property. I see that in the current
>> Hibernate
>> Search it is possible to do it by using the system property "indexBase"
>> (s. DirectoryProviderHelper#IND
> Proposal for next versions: allow @Stereotype - like user annotations?
> We would let the user define custom annotations to stack/combine
> multiple framework annotations, possibly centralizing what the
> "default" is for your app and reduce the amount of code people have to
> pile on each gette
On Tue, May 8, 2012 at 12:27 PM, Sanne Grinovero wrote:
> Proposal for next versions: allow @Stereotype - like user annotations?
> We would let the user define custom annotations to stack/combine
> multiple framework annotations, possibly centralizing what the
> "default" is for your app and reduc
On 8 May 2012 10:43, Guillaume Smet wrote:
> Hi,
>
> On Tue, May 8, 2012 at 10:20 AM, Hardy Ferentschik
> wrote:
>>> Sanne also suggested an alternative solution. We may introduce a new global
>>> option which would define the default value for Field#norms(). The default
>>> value of this option
Hi,
On Tue, May 8, 2012 at 10:20 AM, Hardy Ferentschik wrote:
>> Sanne also suggested an alternative solution. We may introduce a new global
>> option which would define the default value for Field#norms(). The default
>> value of this option would be obviously YES. Users like me could change it
On May 7, 2012, at 11:54 PM, Sanne Grinovero wrote:
>> And our implementation
>> does not produce messages if it creates directories for indexes. I'm
>> personally not
>> interested in the fact that Hibernate Search creates some directories (btw.
>> IMHO it should
>> be logged with info level a
On May 7, 2012, at 11:47 PM, Andrej Golovnin wrote:
> the default value of norms() in the Field annotation is defined to YES.
> I doubt it is always needed, e.g. if you have an Enum field, do you really
> need norms for it? The same applies to long/int, boolean, date, OID fields
> and very short
Hi Guenther,
>>> Is it possible to disable prepared statement caching for batched fetching,
>>> so I end up with a single query in the < default_batch_fetch_size case only
>>> >>instead of the
>>> fixed-size batch loading hibernate does by default?
> I think the main reason for no feedback so f
11 matches
Mail list logo
