[ 
https://issues.apache.org/jira/browse/SOLR-12441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mosh updated SOLR-12441:
------------------------
    Description: 
As discussed in [SOLR-12298|https://issues.apache.org/jira/browse/SOLR-12298], 
there ought to be an URP to add metadata fields to childDocuments in order to 
allow a transformer to rebuild the original document hierarchy.

{quote}I propose we add the following fields:
 # __nestParent__
 # _nestLevel_
 # __nestPath__

__nestParent__: This field wild will store the document's parent docId, to be 
used for building the whole hierarchy, using a new document transformer, as 
suggested by Jan on the mailing list.

_nestLevel_: This field will store the level of the specified field in the 
document, using an int value. This field can be used for the parentFilter, 
eliminating the need to provide a parentFilter, which will be set by default as 
"_level_:queriedFieldLevel".

_nestLevel_: This field will contain the full path, separated by a specific 
reserved char e.g., '.'
 for example: "first.second.third".
 This will enable users to search for a specific path, or provide a regular 
expression to search for fields sharing the same name in different levels of 
the document, filtering using the level key if needed.
{quote}

  was:
As discussed in [SOLR_12298|https://issues.apache.org/jira/browse/SOLR-12298], 
there ought to be an URP to add metadata fields to childDocuments in order to 
allow a transformer to rebuild the original document hierarchy.

{quote}I propose we add the following fields:
 # __nestParent__
 # _nestLevel_
 # __nestPath__

__nestParent__: This field wild will store the document's parent docId, to be 
used for building the whole hierarchy, using a new document transformer, as 
suggested by Jan on the mailing list.

_nestLevel_: This field will store the level of the specified field in the 
document, using an int value. This field can be used for the parentFilter, 
eliminating the need to provide a parentFilter, which will be set by default as 
"_level_:queriedFieldLevel".

_nestLevel_: This field will contain the full path, separated by a specific 
reserved char e.g., '.'
 for example: "first.second.third".
 This will enable users to search for a specific path, or provide a regular 
expression to search for fields sharing the same name in different levels of 
the document, filtering using the level key if needed.
{quote}


> Add deeply nested documents URP
> -------------------------------
>
>                 Key: SOLR-12441
>                 URL: https://issues.apache.org/jira/browse/SOLR-12441
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: mosh
>            Priority: Major
>
> As discussed in 
> [SOLR-12298|https://issues.apache.org/jira/browse/SOLR-12298], there ought to 
> be an URP to add metadata fields to childDocuments in order to allow a 
> transformer to rebuild the original document hierarchy.
> {quote}I propose we add the following fields:
>  # __nestParent__
>  # _nestLevel_
>  # __nestPath__
> __nestParent__: This field wild will store the document's parent docId, to be 
> used for building the whole hierarchy, using a new document transformer, as 
> suggested by Jan on the mailing list.
> _nestLevel_: This field will store the level of the specified field in the 
> document, using an int value. This field can be used for the parentFilter, 
> eliminating the need to provide a parentFilter, which will be set by default 
> as "_level_:queriedFieldLevel".
> _nestLevel_: This field will contain the full path, separated by a specific 
> reserved char e.g., '.'
>  for example: "first.second.third".
>  This will enable users to search for a specific path, or provide a regular 
> expression to search for fields sharing the same name in different levels of 
> the document, filtering using the level key if needed.
> {quote}



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to