Thanks, great feedback as always.
> the filtering idea is looking great.
> I'm wondering how this affects performance, but I guess we can focus
> on API and feature for now.
Right. I am most interested in getting the API right atm.
Do you think that filtering has a worse performance than executin
2011/3/14 Hardy Ferentschik :
> Thanks, great feedback as always.
>
>> the filtering idea is looking great.
>> I'm wondering how this affects performance, but I guess we can focus
>> on API and feature for now.
>
> Right. I am most interested in getting the API right atm.
> Do you think that filter
On 14 mars 2011, at 11:46, Sanne Grinovero wrote:
>>
>>
>> What you are loosing by query.getFacets( facetName ) is the ability to
>> iterate over the
>> enabled facets. At the very least you have to take care yourself of which
>> facet names are set.
>> In intermediate step would be to get rid
Hi Oliver,
create a local branch to keep it, branching out of master:
git checkout -b Sanne-HSEARCH-323 master
now pull in my branch:
git pull https://sa...@github.com/Sanne/hibernate-search.git HSEARCH-323
Now you have it all, you can use "git log" to verify you have the commits,
or "git form
On 14 mars 2011, at 12:03, Emmanuel Bernard wrote:
>
> On 14 mars 2011, at 11:46, Sanne Grinovero wrote:
>
>>>
>>>
>>> What you are loosing by query.getFacets( facetName ) is the ability to
>>> iterate over the
>>> enabled facets. At the very least you have to take care yourself of which
>>>
As you guys know I've not been comfortable with the idea of reusing Filter as
an implementation as it seem to be it is an implementation detail that we might
change down the road and that is of no interest to the user.
Instead of bitching abstractly, I've decided to implement a CDI style bean th
Note that another benefit of option 2 is that we can down the road (post 3.4)
implement a way to pre-select which facet element is enabled (say you want to
filter by Epson and Canon by default for the first query).
facet().name("Brand")
.onField("brand")
.discrete()
.select("Epson", "Canon
> As you guys know I've not been comfortable with the idea of reusing Filter as
> an implementation as it seem to be it is an implementation detail that we
> might change down the road and that is of no interest to the user.
I didn't understand you where exposing the filter, as I said in
previou
On Mon, 14 Mar 2011 15:43:20 +0100, Emmanuel Bernard
wrote:
> Note that another benefit of option 2 is that we can down the road (post
> 3.4) implement a way to pre-select which facet element is enabled (say
> you want to filter by Epson and Canon by default for the first query).
>
> facet(
On Mon, 14 Mar 2011 15:00:59 +0100, Emmanuel Bernard
wrote:
> Actually, I think we should have a FacetManager interface that hosts all
> the facet related methods of FullTextQuery
> ftQuery.getFacetManager().enableFacet( "oh-my" );
>
> It's easier for people to find and that can be reused by
On Mon, 14 Mar 2011 15:29:03 +0100, Emmanuel Bernard
wrote:
> While implementing it I've found several proposals for enhancement:
> - should we rename in thw facet DSL createFacet to
> createFacetRequest(), as it's the object returned
+1
> - jpa.FullTextQuery does not have the facet method
On 14 mars 2011, at 16:33, Hardy Ferentschik wrote:
>> - move Facet methods hosted on FTQuery to a FacetManager interface and do
>> ftQuery.getFacetManager().enableFacet("cdscds");
> no sure about this one. What other benefits does this approach have except
> the reuse for the JPA query?
My con
On 14 mars 2011, at 16:33, Hardy Ferentschik wrote:
> On Mon, 14 Mar 2011 15:43:20 +0100, Emmanuel Bernard
> wrote:
>
>> Note that another benefit of option 2 is that we can down the road (post
>> 3.4) implement a way to pre-select which facet element is enabled (say you
>> want to filter by
Hello,
while debugging I just noticed that having a two entities scenario like
@Indexed class Book {
Long id;
@IndexedEmbedded Nation bublishedFirstIn;
}
Nation { //NOT indexed
Long id;
@Field name
}
the index for Book will contain these fields:
_hibernate_class - NOT_ANALYZED_NO_NO
14 matches
Mail list logo
