[Hibernate-JIRA] Created: (HSEARCH-713) Drill-down faceting query should not affect other facet counts
by Sanne Grinovero (JIRA)
Drill-down faceting query should not affect other facet counts
--------------------------------------------------------------
Key: HSEARCH-713
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-713
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Sanne Grinovero
Assignee: Hardy Ferentschik
Fix For: 3.4.0
Using the "drill-down" function in faceting should - at least by default - behave like Amazon's faceting: it affects the filtering of the list shown as current results but should not affect the faceting count of other facets.
(It will of course affect sub-facets, so people can navigate up/down the facet tree to narrow down the results and explore different branches, but the parent branch and it's peers shouldn't be affected.
It's still possible to apply global filters which affect all facets (like a filter applied on root): example enable "only items with at least 4 star reviews" might affect all counters in the tree.
But if I'm in the area "TVs", and then the options {"LED", "Plasma"} open up, when we select "LED" the counters for both "Plasma" and "LED" should not change -> just of course the main results list will show only LED televisions.
For those people who think it should be possible to affect such a drill down feature as a filter, they can still apply the filter globally (on the root query).
{quote}<emmanuel> but to move forward, let's start with what we have. It seems that such alternative are definitely going to be an option on the FacetedManager
<emmanuel> facetedManager.countAs(AMAZON) :){quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HSEARCH-349) Allow custom Loader in FullTextQueryImpl
by Julien Kronegg (JIRA)
Allow custom Loader in FullTextQueryImpl
----------------------------------------
Key: HSEARCH-349
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-349
Project: Hibernate Search
Issue Type: New Feature
Components: query
Affects Versions: 3.1.0.GA
Environment: Hibernate 3.3.1.GA, DB2
Reporter: Julien Kronegg
Priority: Minor
When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code:
List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList();
The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names.
This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene).
Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database.
This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as:
private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) {
if (customLoader!=null) {
customLoader.init(session, sessionFactoryImplementor);
return customLoader;
}
...
}
After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list".
There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HSEARCH-810) @NumericFields with NumericField forName require @Field to use name=
by Izaak Alpert (JIRA)
@NumericFields with NumericField forName require @Field to use name=
--------------------------------------------------------------------
Key: HSEARCH-810
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-810
Project: Hibernate Search
Issue Type: Bug
Reporter: Izaak Alpert
Priority: Minor
It seems that unless name for the first @Field is specified range searches on that field will not be numeric
Doesn't work:
public class TestExampleClass {
@Fields({
@Field( index = Index.UN_TOKENIZED),
@Field(name = "quantityFitted_forSort", index = Index.UN_TOKENIZED, store = Store.YES) })
@NumericFields({ @NumericField(forField = "quantityFitted") })
private Integer quantityFitted;
}
public class TestExampleClass {
@Fields({
@Field(name = "quantityFitted", index = Index.UN_TOKENIZED),
@Field(name = "quantityFitted_forSort", index = Index.UN_TOKENIZED, store = Store.YES) })
@NumericFields({ @NumericField(forField = "quantityFitted") })
private Integer quantityFitted;
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months