Hello,
Using the entryCount was our first option, but we decided to modify
costPerEntry instead. Basically these are the reasons:
- It can only be used to reduce the cost. It can't be used to increase
the index cost as the index-planner selects
Math.min(definition.getEntryCount(),
getRe
Hi Tomek,
yes I'm trying to upgrade within the same repository type but I can decide
weather to migrate the repository or not based on what makes the upgrade
easier.
The CommitHooks can only be used inside an upgrade to a new repository?
What is the suggested way to apply backward-incompatible chan
Having same asset indexed twice would add overhead in terms of async
indexing speed and space consumption by index. So if possible avoid
such a setup
> We could assume that we always add a path restriction, but I'm not sure how
> index movement can help. I mean, both indexes contains documents und
Hello,
I'm not sure about the text extraction, as other team is in charge of it.
But the repository is quite big.
We could assume that we always add a path restriction, but I'm not sure how
index movement can help. I mean, both indexes contains documents under
/nodeA/nodeB/nodeC so any query und
> - Rebuilding Assets index takes several days
Is the time spent in text extraction?
Would the code always specify path restriction in the queries for
my:Asset? If yes then you can just move the index definition under
respective paths
Would that be an option
Chetan Mehrotra
On Tue, May 16, 20
Hello,
Yes, there are some reasons:
- One team is working with all the assets under /nodeA/nodeB
- Other team only works with an small subset, only assets under
/nodeA/node/nodeC
- Both teams have different searching requirements
- Rebuilding Assets index takes several days
- Re
Any reason for having separate definitions for same nodetype?
Chetan Mehrotra
On Tue, May 16, 2017 at 7:52 PM, Alvaro Cabrerizo wrote:
> Hello,
>
> Actually, it is OAK-5449. Sorry, I hadn't seen it.
>
> On the other hand, having these two definitions under oak:index (just a
> sketch):
>
>
>-
Hello,
Actually, it is OAK-5449. Sorry, I hadn't seen it.
On the other hand, having these two definitions under oak:index (just a
sketch):
- Asset
- evaluatePathRestrictions="true"
- type="lucene"
- includedPath="/nodeA/nodeB"
- indexRules
- my:Asset
- pro
Hi Marco,
the main purpose of the oak-upgrade is to migrate a Jackrabbit 2 / CRX2
repository into Oak or to migrate one Oak node store (eg. segment) to another
(like Mongo). On the other hand, it’s not a good choice to use it for the
application upgrades within the same repository type. You did
This looks similar to OAK-5449 (not yet fixed). Can you give a sample
index definition there and some usecase details which is leading to
ambiguity in index selection.
In general index selection should not have multiple competing index
definitions hence interested in knowing setup details
Chetan M
Hello guys,
Our server is going out of memory due to insufficient metaspace. When analysing
the heapdump that was created we also noticed in the Eclipse Memory Analyser
that the is a possible memory leak suspect in
org.apache.jackrabbit.oak.cache.CacheLIRS
The information shown by the applicat
Hello,
I've been checking the code of the IndexPlanner (apache OAK 1.4.1) and I
was surprised because the costPerEntryFactor remains 1 in both cases:
- when no property indexed or sorted match any property clause or sort
clause from the query
- when only an indexed or sorted property mat
12 matches
Mail list logo