You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2015/12/16 08:09:47 UTC

[jira] [Comment Edited] (OAK-2511) Support for faceted search in Lucene index

    [ https://issues.apache.org/jira/browse/OAK-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15059600#comment-15059600 ] 

Chetan Mehrotra edited comment on OAK-2511 at 12/16/15 7:09 AM:
----------------------------------------------------------------

[~teofili] Had a look at the commit and have some comments. Kindly have a look

*A - Config*

# Property definition name - Instead of {{facets}} it might be better to use {{faceted}}
{noformat}
     /**
+     * Optional (property definition) property indicating facet can be retrieved together with plain queries.
+     * Default is false
+     */
+    String PROP_FACET = "facets";
{noformat}
# Facets config - Currently there is one {{secureFacets}}. Would we later expose more config to ow facets are managed? If yes then have a node {{facets}} and then move this config under that. This would help in keeping all facet config at one place



*B - Change in LuceneIndexEditor*

# facetsConfig is static. It does not look like to be stateless
{code}

+    private static final FacetsConfig facetsConfig = new FacetsConfig();
+
{code}
# Move facet field name logic to {{FieldNames}} class
{code}
+            String facetFieldName = pname + "_facet";
{code}
# Better to move this logic to PropertyDefinition#validate and have it as stats set. Easier to update later!
{code}
+    private boolean addFacetFields(List<Field> fields, PropertyState property, String pname, PropertyDefinition pd) {
+        // force skipping some JCR properties whose faceting wouldn't make sense (unique or possibly very large values)
+        if (!pname.equals(JCR_DATA) && !pname.equals(JCR_CREATED) && !pname.equals(JCR_UUID)) {
{code}
# *Facet and field Type* - Current impl looks like creats faceted field for all type. It would be better to restrict it to String type. For other types I am not sure if it makes sense. If we see valid usecase later we can enable that
# *Faceting and relative properties* - Current approach would not work for relative properties. If you create facet fields from within {{indexProperty}} then it would be called from both {{makeDocument}} for immediate properties and {{indexAggregates}} for relative properties. 

*C - Changes in LucenePropertyIndex*

# {{loadDocs}} method is now becoming too big and doing lots of things. We should move faceting logic to separate method. I can take care of this
# (minor)Move Facet field logic to {{IndexPlan}} as part of {{IndexPlanner#getPlanBuilder}} call where it iterates over the property definitions. 
{code}
+                        List<String> facetFields = new LinkedList<String>();
+                        List<PropertyRestriction> facetRestriction = filter.getPropertyRestrictions(QueryImpl.REP_FACET);
+                        if (facetRestriction != null && facetRestriction.size() > 0) {
+                            for (PropertyRestriction pr : facetRestriction) {
+                                String value = pr.first.getValue(Type.STRING);
+                                facetFields.add(value.substring(QueryImpl.REP_FACET.length() + 1, value.length() - 1));
+                            }
+                        }
{code}
# Use PERF_LOGGER instead of System.currentTimeMillis()
{code}
+                                long f = System.currentTimeMillis();
+                                for (String facetField : facetFields) {
{code}
# (minor) Facet field name logic to a method
{code}
#395 - facetFields.add(value.substring(QueryImpl.REP_FACET.length() + 1, value.length() - 1));
#1548 String facetFieldName = columnName.substring(QueryImpl.REP_FACET.length() + 1, columnName.length() - 1);
{code}


was (Author: chetanm):
[~teofili] Had a look at the commit and have some comments. Kindly have a look

*A - Config*

# Property definition name - Instead of {{facets}} it might be better to use {{faceted}}
{noformat}
     /**
+     * Optional (property definition) property indicating facet can be retrieved together with plain queries.
+     * Default is false
+     */
+    String PROP_FACET = "facets";
{noformat}
# Facets config - Currently there is one {{secureFacets}}. Would we later expose more config to ow facets are managed? If yes then have a node {{facets}} and then move this config under that. This would help in keeping all facet config at one place



*B - Change in LuceneIndexEditor*

# facetsConfig is static. It does not look like to be stateless
{code}

+    private static final FacetsConfig facetsConfig = new FacetsConfig();
+
{code}
# Move facet field name logic to {{FieldNames}} class
{code}
+            String facetFieldName = pname + "_facet";
{code}
# *Facet and field Type* - Current impl looks like creats faceted field for all type. It would be better to restrict it to String type. For other types I am not sure if it makes sense. If we see valid usecase later we can enable that
# *Faceting and relative properties* - Current approach would not work for relative properties. If you create facet fields from within {{indexProperty}} then it would be called from both {{makeDocument}} for immediate properties and {{indexAggregates}} for relative properties. 

*C - Changes in LucenePropertyIndex*

# {{loadDocs}} method is now becoming too big and doing lots of things. We should move faceting logic to separate method. I can take care of this
# (minor)Move Facet field logic to {{IndexPlan}} as part of {{IndexPlanner#getPlanBuilder}} call where it iterates over the property definitions. 
{noformat}
+                        List<String> facetFields = new LinkedList<String>();
+                        List<PropertyRestriction> facetRestriction = filter.getPropertyRestrictions(QueryImpl.REP_FACET);
+                        if (facetRestriction != null && facetRestriction.size() > 0) {
+                            for (PropertyRestriction pr : facetRestriction) {
+                                String value = pr.first.getValue(Type.STRING);
+                                facetFields.add(value.substring(QueryImpl.REP_FACET.length() + 1, value.length() - 1));
+                            }
+                        }
{noformat}
# Use PERF_LOGGER instead of System.currentTimeMillis()
{noformat}
+                                long f = System.currentTimeMillis();
+                                for (String facetField : facetFields) {
{noformat}





> Support for faceted search in Lucene index
> ------------------------------------------
>
>                 Key: OAK-2511
>                 URL: https://issues.apache.org/jira/browse/OAK-2511
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: lucene
>            Reporter: Tommaso Teofili
>            Assignee: Tommaso Teofili
>             Fix For: 1.3.13
>
>
> A Lucene index should be able to provide faceted search results, based on the support provided in the query engine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)