Performance issue when finding changes by instanceId with ChildValueObject

[gravity-57]

I use Javers (5.12.0) with MongoDB repository in a production environment for auditing one object with one child.
Currently the snapshots collection contains more than 1 millions documents and we meet performance issue when finding changes by instanceId with child value object :

QueryBuilder queryBuilder = QueryBuilder.byInstanceId(orderId,OrderAudit.class).withNewObjectChanges().withChildValueObjects(); Changes changes = javers.findChanges(queryBuilder.build());

This request takes about 4 seconds to get results.

After debugging,it appears that "withChildValueObjects()" option will generate a regex filter in MongoRepository to retreive child objects:

{"find": "jv_snapshots", "filter": {"$or": [{"globalId_key": "OrderAudit/1818342"}, {"globalId_key": {"$regularExpression": {"pattern": "^OrderAudit/1818342#.*", "options": ""}}}]}, "sort": {"commitMetadata.id": -1}, "limit": 100, "$db": "javers-audit"}

As we can see the query do a filter on exact globalId_key ( very fast as there is an index for this property in Mongo DB ) but the second part with regex filter is very slow.

Have you already see this issue ?
Is there any solution to solve this ?

May be we could filter using globalID.ownerId property ?

"globalId": { "valueObject": "OrderAuditChild", "ownerId": { "entity": "OrderAudit", "cdoId": 1818031 }, "fragment": "child" }

Thanks in advance for your help :)

BR

[bartoszwalacik]

Hi, since you are close to the solution of this issue, please contribute a PR

[gravity-57]

Hi,

I implemented a fix for this performance issue on a local branch. When I tried to push it, I received a permission denied. Miss I something ?
It is the first time I contribute to an open source project so I am not aware of all good practices.

BR

[bartoszwalacik]

Ok, so the standard flow on github looks like that :
you need to fork this repository and create a PR from your fork's branch to this master

for example #1021

[vladimirmutafov]

Hi! Me and my team hit this problem too with a DocumentDB collection with around 4 million objects. I've tried to fix this with #1367 @bartoszwalacik could you please take a look?

[bartoszwalacik]

Fixed in 7.4.1