[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-3767:
-
Fix Version/s: (was: 1.38.0)
1.40.0
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.40.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-3767:
-
Fix Version/s: (was: 1.36.0)
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.38.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-3767:
-
Fix Version/s: 1.38.0
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.36.0, 1.38.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: (was: 1.14.0)
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.16.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: 1.16.0
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.14.0, 1.16.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: (was: 1.12.0)
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.14.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: 1.14.0
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: (was: 1.10.0)
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.12
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: 1.12
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.10.0, 1.12
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3767:
--
Fix Version/s: (was: 1.8)
1.10
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
> Fix For: 1.10
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3767:
-
Issue Type: New Feature (was: Improvement)
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
> Fix For: 1.8
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3767:
-
Description:
We need to provide an explicit support for extending out of the box shipped
index definition by an application built on top of Oak. Consider a Sling based
app which ships with an index on assets like /oak:index/assetIndex. This
application is now used in a project where some project specific extensions are
to be done i.e. some new custom asset properties are to be indexed. Currently
there are two options
# Create new duplicate index - For project usage we can create a separate index
which includes the project specific properties. This has following downsides
## Increases index memory consumption - As both /oak:index/assetIndex and
/oak:index/myAssetIndex would index same asset nodes they would be storing the
same asset path twice and hence cause an increase in memory consumption by the
index
# Increase in indexing time - With increase in number of indexes at same level
the indexing time would increase
# Ambiguity in index selection - As both indexes index same type of nodes they
would compete in answering queries related to assets leading to ambiguity in
index selection by query engine.
Given above it would be better to avoid such cases and provide an explicit
support for extending the index definitions. This can be done by enabling
support for adding index definition extensions under a sub directory in a sub
directory under /oak:index
{noformat}
/oak:index
+ assetIndex
+ apps
+ assetIndex
{noformat}
The indexing logic should then use the effective index definition for indexing
and querying.
*question*. Shall we allow this only under root or under any arbitrary path as
well? For example /content.
was:
Provide the ability to define indexes in subdirectories of an oak:index node.
Something like
{noformat}
/oak:index
-> oak
-> apps
{noformat}
*question*. Shall we allow this only under root or under any arbitrary path as
well? For example /content.
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing, query
>Reporter: Davide Giannella
> Fix For: 1.8
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3767:
-
Summary: Provide a way to extend shipped index definitions (was: define
index in subdirectories of oak:index)
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing, query
>Reporter: Davide Giannella
> Fix For: 1.8
>
>
> Provide the ability to define indexes in subdirectories of an oak:index node.
> Something like
> {noformat}
> /oak:index
> -> oak
> -> apps
> {noformat}
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
