2014-11-05 13:42 GMT+01:00 Chetan Mehrotra <[email protected]>:

> On Wed, Nov 5, 2014 at 3:30 PM, Marcel Reutegger <[email protected]>
> wrote:
> > the your configuration proposal we'd now have three different
> > places where a property can be specified:
> >
> > - includePropertyNames
> > - properties
> > - indexRules
> >
> > would it be possible to unify those definitions into a single one?
>
> yes that needs to be done. This happened because LucenePropertyIndex
> work in whitelist mode while Lucene full text index work in more
> generic mode where you use some common setting for everything and then
> for specific stuff customize it. Hence the need for
> 'includePropertyNames' to provide the whitelist of property names and
> 'properties'  to capture property specific changes.
>
> So thinking more about it I think its better to use JR config model
> and map it to content tree. So the proposed model would be something
> like
>
> -----------------------------
>         "indexRules" : {
>             //need orderable child nodes to honour
>             //nodeType hierrachy
>             "jcr:primaryType": "nt:unstructured",
>             "nt:unstructured" : {
>                 "properties" :{
>                     "title" : { /* Scoped property */
>                         "boost" : 1.5
>                     }
>                 }
>             },
>             "nt:file" : {
>                 "boost" : "2.0",
>                 "condition" : "@priority = 'high'"
>             },
>             "app:Asset" : {
>                 "properties": {
>                     "jcr:primaryType":"oak:Unstructured",
>                     //relative property jcr:content/lastModified
>                     "jcr:content": {
>                         "jcr:primaryType":"oak:Unstructured",
>                         "jcr:lastModified": {
>                             "jcr:primaryType":"oak:Unstructured",
>                             "type":"Date"
>                         }
>                     }
>             },
>             "nt:base" : {
>                 "properties" :{
>                      //need orderable property nodes
>                      //to support regexp
>                     "jcr:primaryType": "nt:unstructured",
>                     "offTime" : {
>                         "nodeScopeIndex" : false
>                     }
>                 }
>             }
>         }
> -----------------------------
>
> Above model would super cede current config options
>
> * declaredNodeTypes - This can be computed from the indexRules child node
> list
> * relativeProperties - The relative property names would also be
> scoped to there nodeType
> * includePorpertyName - A property would be included if it passes any
> of the index rules
>
> @Tommaso - I think using nodeType as the node name instead of
> arbitrary name would remove redundancy
>

ok


>
> Given existing config is part of 1.0.8 we would need to support both
> but users would not be allowed to mix both approaches.
>

right, what about making the field name the common ancestor for both
unscoped and scoped properties? :

"properties": {
            "title" : { "boost" : 2.0, /* Unscoped property */
                           "nt:unstructured" : { "boost" : 1.5 }, /* scoped
property */
                           "nt:file" : { "boost" : 1.2 } /* scoped property
*/
                       }
        },

the drawback is that you would have to define a similar structure for each
field to be boosted for each node type, the advantage is that it's
compliant with what we have in 1.0.8.

Regards,
Tommaso


>
> Thoughts?
>
>
> Chetan Mehrotra
>

Reply via email to