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
> 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
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.
Sounds good.
If you go the interface route then fine
If you go the annotation route, use the existing @Factory annotation
we have. You can also check the code to see how it's implemented for
filter.
On 2 déc. 09, at 19:29, Sanne Grinovero wrote:
> Hi Amin,
> no problem go ahead do some experi
