Unit tests are automatically run on every build as part of the build process, but unfortunately in this case the test verified that the data is fetched with the query results (which worked, no additional access to the database was required to access the data, if done before closing the EntityManager) but not that the relationship is activated. The unit tests were also fixed following your report.

1- There are currently no known issues regarding indexes that become broken, but everything could happen. It is more likely that the index is fine and a bad optimization causes this in a specified case.

2- Using the Doctor. You can also run it in repair mode and then the index will be rebuilt cleanly.

3- You can try "SELECT e.indexedAttr, e.id FROM MyEntity e ORDER BY e.indexedAttr" and check the results.

I have spent too many hours to find a test case and if i find it, it will be the third bug about the "join fetch" feature. 3 bugs discovered in few days ... i'm afraid to find more in the future, so let's stop the investigation.

I switched back to ALL EAGER ( seems to be faster ... ) and stoped all kind of lazy initialization.

Left join is not enough mature in objectdb to use in a production environment.

If ALL EAGER is faster in your application then you should use it anyway. We will take into account your reports regarding JOIN FETCH. Obviously more extensive tests are required in order to cover this feature better.

More than simple unit test case, I think you should realise some complex test case ( multi join fetch + various jpa collection combinaison + various cascade combinaison + merge / persist parents and childs + add indexes ) to bere sure all is fine no matter the case complexity. ( watch the mapped-by + left join test case, that was so weird, but could be prevented by complete scenario )

> Although you are moving back to ALL EAGER, will you be able to check JOIN FETCH with some optimization disabled? This could help us understand where is the issue.

Yes, without index on the collection, all if fine, but performances are weak.

I think the combo Hibernate + H2 works better ( see http://zeroturnaround.com/rebellabs/how-to-use-jpa-correctly-to-avoid-complaints-of-a-slow-application/ ). Indeed for H2 + Hibernate that's the best solution ! And the worst for ObjectDb.

Also ...

In objectDb the N+1 problem (mentionned in the website) seems to not exist. Performances are also better than EAGER (need to be confirmed, it seems suspicious). In facts, looping in each object to lazy load each collection is the best solution.

To finish, eager fetch all collection is a bit slower than lazy load, that's surprising so ...

Support, if you can provide some tests or give some benchmarks, it could be great.

So, in brief :

-> Left join fetch is buggy, doesn't fetch some entities in some cases ( haven't tested no optimization yet )

-> Left join fetch performances are very very bad, i think hibernate + h2 work really better ( see benchmark )

-> Mapped by attribute is really buggy !!! In some case, it's 60x slower with it.

-> Lazy load of all collections seems to be better than All eager strategy (well here, this is very suspicious :/).

Support, you should add some benchmarks to your test case, because buggy implementations could make the test right but slow.

It's would also be really great to put these new benchmarks in your existing charts.

Interesting results. Different methods are faster/slower in different conditions so there are no rules that match every situation, and the only way to find out what is best for a specific application is to benchmark the alternatives.

Regarding lazy initialization with size(), it looks strange that it is faster than EAGER if referenced objects are fetched. But check that the referenced objects are indeed retrieved, because ObjectDB can return a collection size and initialize the collection with hollow referenced objects.