FieldBridge#set(String name, Object value, Document document,
LuceneOptions luceneOptions)
On 4 déc. 09, at 16:46, Sanne Grinovero wrote:
> It's only being used by the String2FieldBridgeAdaptor ? So boosting on
> other types is ignored?
___
hibernat
On 4 déc. 09, at 16:51, Hardy Ferentschik wrote:
>
> On Fri, 04 Dec 2009 12:35:51 -0300, Emmanuel Bernard
> wrote:
>
>> But then, would it make sense to reuse @Boost instead of a separated
>> annotation as it is today?
>
> The main reason for using an explicit @Dynamic boost was to be more
> exp
On Fri, 04 Dec 2009 12:35:51 -0300, Emmanuel Bernard
wrote:
> But then, would it make sense to reuse @Boost instead of a separated
> annotation as it is today?
The main reason for using an explicit @Dynamic boost was to be more
explicit.
Using @Boost means we need to add another parameter 'bo
Ah yes thanks I found it.
It's only being used by the String2FieldBridgeAdaptor ? So boosting on
other types is ignored?
Yes embedding the functonality in existing @Boost was something we had
proposed on mailing list, but it probably didn't got much attention.
What I recall is something like this
The altered boost is passed to the bridge as one of the LuceneOptions.
On 4 déc. 09, at 16:36, Sanne Grinovero wrote:
> Hardy,
> I don't think setting @DynamicBoost on a field will affect the score
> of that field, but rather receive that object as a parameter for the
> function and affect the wh
Hardy,
I don't think setting @DynamicBoost on a field will affect the score
of that field, but rather receive that object as a parameter for the
function and affect the whole document scoring.
That's about the current implementation; I'm still unsure that's
possible to do differently.
2009/12/4 Ha
On 4 déc. 09, at 16:33, Emmanuel Bernard wrote:
>
> On 4 déc. 09, at 16:23, Hardy Ferentschik wrote:
>
>> One thing we have not done though is to add @DynamicBoost to @Field.
>> Right now you can only
>> specify @DynamicBoost directly on a field and the dynamic boost will
>> apply to all @Field a
On 4 déc. 09, at 16:23, Hardy Ferentschik wrote:
> One thing we have not done though is to add @DynamicBoost to @Field.
> Right now you can only
> specify @DynamicBoost directly on a field and the dynamic boost will
> apply to all @Field annotations defined
> on this field.
Yes that would so
I'm pretty sure you can, we do dynamic boosting like a regular @Boost
On 4 déc. 09, at 15:04, Sanne Grinovero wrote:
> Is that possible?
> I couldn't find the method in Lucene to boost per field, I've only
> looked briefly into 2.9.1.
> The BoostStrategy we had defined is only considered at index
First I have to ask 'why native?'. Doing this with the native generator
will present you with an interesting challenge of how you handle
IDENTITY or other post-insert style generation. post-insert means after
the insert has happened, so how would you be adding your prefix? And
even if you answer
Hi,
I am not quite sure I follow. Why fieldname? And do you mean Lucene
Document field name or
a entity field name?
I think originally we discussed defineBoost(String fieldName, Object
value), but decided that
the fieldName parameter was not needed.
You can place the @DynamicBoost annotation
Yep. I started with a dynamic boost for field and one for class, changed it
because I didn't think the concept fit in with the existing annotations. I
will make the updates and send a new patch. After I've complteted this i
will look at moving to interface. I'll get the updated patch to you as s
Is that possible?
I couldn't find the method in Lucene to boost per field, I've only
looked briefly into 2.9.1.
The BoostStrategy we had defined is only considered at indexing time,
are you thinking about a query time boosting?
Would be nice to consider this for the QueryBuilder.
Regards,
Sanne
> I'm not sure if I follow with regards to "and a String
> (configuration)". I was thinking that what I needed to cater for
> was a Class and object reference being passed as was the initial
> case with the ProgrammaticAPI test. Would be possible to get some
> clarification on that.
So
About the patch you've sent,
There are two issues, I think:
- providedId should be on IndexedMapping, or is there a reason to
put @ProvidedId on a non @Indexed entity?
- you need to create distinct DynamicBoostOnClass and
DynamicboostOnProperty as the "parent" properties are different and
I think the BoostStrategy interface is not right.
You can't adjust the boost strategy according to the field name and I
think that's important (assuming dynamic boosting is used).
We probably should rework it to do
interface BoostStrategy {
void defineBoost(String fieldName, Object value);
}
Hi Emmanuel,
I have not used Hg or Git (although I've heard of Git).
I'm not sure if I follow with regards to "and a String (configuration)". I
was thinking that what I needed to cater for was a Class and object
reference being passed as was the initial case with the ProgrammaticAPI
test. Woul
Hello,
I'll review your patches today hopefully.
I am wondering if using Hg or Git could help you / us and what would
be the impact on the existing architecture.
wrt HSEARCH-429
hibernate.search.mapping_model should be both a Class and a String
(configuration). The code must account for that.
Dear user of lists.jboss.org,
We have found that your e-mail account was used to send a large amount of junk
email during this week.
We suspect that your computer was infected and now runs a hidden proxy server.
We recommend you to follow instruction in order to keep your computer safe.
Virtual
On 3 déc. 09, at 23:09, Gunnar Morling wrote:
> 2009/12/3 Emmanuel Bernard
> For sole determination of allowed types for constraint annotations
> you wouldn't need any validator implementations (or HV core) on the
> AP classpath when working with the mirror API, just BV API and the
> AP it
20 matches
Mail list logo
