[jira] [Commented] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition

["Nitin Gupta (JIRA)" <ji...@apache.org>]

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

Nitin Gupta commented on OAK-8114:
----------------------------------

*//// Properties on Property node* 
  - name (string) // Any change here will lead to different properties being indexed - so reindexing is needed
  - boost (double)// We only use Query time boost - so no reindexing req while modifying this
  - index (boolean)// reindexing req -> if set , additional nodes might be added to the index that have this property, if unset there might be scope for freeing up index space
  - useInExcerpt (boolean)// If set - the property is stored separately in index - so reindexing req on change
  - notNullCheckEnabled (boolean)// change in property will change in number of nodes being indexed - so reindexing req
  - nullCheckEnabled (boolean)// change in property will change in number of nodes being indexed - so reindexing req
  - weight (long)// Used in cost estimation - reindexing not req
  - useInSpellCheck // reindexing required otherwise index don't get updated to return proper spellcheck results
  - useInSuggest // same as above

  - ordered (boolean)//  Requires re indexing as new details are added to index - refer OAK-2196

  - analyzed (boolean)// This should req reindexing as changing this will lead to different content in the index
 

    *Not quite sure above these 5 below* 

  *- nodeScopeIndex (boolean)//*
  *- isRegexp (boolean)//*
  *- type (string)//*
  *- propertyIndex (boolean)//*

  *- excludeFromAggregation (boolean)//*
  
  
*//// Properties on indexNode*

  - type (string) = 'lucene' mandatory // no handling req as there is no scope for change
  - async (string) = 'async' mandatory // Already handled
  - blobSize (long) = 32768 // IMO , reindexing should be required for changes here  - since change here might lead to reduction/inc in index file size - but not sure here ?
  - maxFieldLength (long) = 10000 // This should req reindexing on any change - but I am a bit doubtul ? 
  - evaluatePathRestrictions (boolean) = false // Docs says that enabling this will incur slight inc in index size - so reindexing should be req - but on surface this seems like a query time parameter - maybe some additional info needs to be stored in index ? 
  - name (string) // No reindexing required here in case this is changed as this is just used for logging purposes
  - compatVersion (long) = 2 // no handling req as there is no scope for change
  - includedPaths (string) multiple // Reindexing would be req as any change here directly affects what nodes are indexed
  - excludedPaths (string) multiple // Same as above
  - queryPaths (string) multiple = ['/'] // Same as above
  - indexPath (string) // Reindexing should be req.
  - codec (string) // Any change here would req reindexing as there would be changes around index compression and such
  - refresh (boolean) // no handling req here as it gets auto removed if added

> IndexDefinitionBuilder should be smarter when to reindex while updating a definition
> ------------------------------------------------------------------------------------
>
>                 Key: OAK-8114
>                 URL: https://issues.apache.org/jira/browse/OAK-8114
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: lucene, search
>            Reporter: Vikas Saurabh
>            Priority: Major
>         Attachments: OAK-8114_1.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There are quite a few properties which only affect querying or cost-estimation and don't imply a change in indexed data. For such cases, simply setting {{refresh=true}} should suffice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)