Explorer bug ? Objects seem to be missing from database in Class view, but are present as references

I suspect the following is an Explorer bug. It is marked knowingly as CRITICAL by me because it makes the ObjectDB system unusable for a real project because it appears to be either database integrity corruption, or it just looks like it, which is just as bad.

I attach a running project illustrating the problem, as well as screenshots.

When the project runs it logs creation of objects. Please note that there are 2 Project objects, and note that every Element object (except Project itself) gets a Project reference on construction:

We see that 2 Project objects were created, however in the database Explorer it lists size=0 for Project class (see 1st image attachment).

But if your look, say, under field project in a Block object, it can be seen that there is in fact a Project referenced (see 2nd image attachment), but please note carefully that its fields (such as name) are null, it is in fact a broken Project object (or looks like it).

Please attend to this very serious problem as soon as possible so that I can resume my evaluation of ObjectDB and report my client, the end-customer (without having to tell them of further bugs in the ObjectDB system),

Unfortunately it is a critical bug - it is not the Explorer but somehow your application generated a broken database.

It might be related to the flush bugs that are being fixed in the last builds so please check it with build 2.2.5_09.

I tried to run your test application but I got the following exception:

Caused by: javax.ejb.EJBException: Attempt to persist a reference to a non managed com.greensoft.entity.Block instance
at com.greensoft.ejb.RequestBean.createBlock(RequestBean.java:90)
at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)

So if this is not solved by build 2.2.5_09 - help with running the test case would be needed.

I tried your test program with a new build 2.2.5_10 - and it seems to work well (see attached odb).

All the problems that you have reported till now are related to using flush extensively (many times until commit). You should avoid this to improve performance, but of course - ObjectDB must be able to handle such activity without errors.

Thank you very much for your bug reports that hit an issue that was not addressed well by ObjectDB till now.

> All the problems that you have reported till now are related to using flush extensively (many times until commit).

Before testing build .._10, as a separate topic.

Just to clarify; I do not want to have to use flush extensively, it is only there to address the fact that under @ID @GeneratedValue AUTO strategy with ObjectDB (unlike with EclipseLink+MySQL or EclipseLink+Oracle) the id is not available, as reported here:

Your EntityManager seems not to grant an id to external object after em.persist(object), which is causing me trouble with wiring (www.objectdb.com/ticket/305)

If you are the person who handled this issue but have not read or dealt with that support ticket above, please read it, it is important to understand. It seems with ObjectDB I would have to switch to TABLE or SEQUENCE strategy instead of AUTO to get an ID ensured after just persist. Note also and please read (and please read external links) if have not already the forum posting summary:

Ok, I've tested objectdb-2.2.5_10 on the larger test sequence of ConfigBean (not just the smaller one in ObjectdbTest) and after inspecting at least the cases reported as errors at http://www.objectdb.com/database/support/128 and above seem to be fixed, the constraint/contrainedElements relationships corresponding to the test case sequence appear correct, and the once "missing" objects reported in this issue are now correctly present, so a tentative congratulations is in order.

Thanks for attending to this bug, and for taking the care this time to compare with the offered test case both in my logged output and by examining the result in the Explorer (which it seems is not at fault).