Modifying something with Explorer -> app JPQL with Enum doesn't work anymore

Hi! Scenario:

1. Copy attached DB into localhost ObjectDB server (I'm running 2.5.1_03).
2. Open attached project JavaEE Maven with NetBeans (7.4 beta in my case).
3. Start ObjectDB on localhost as server.
4. Run project on Apache Tomee 1.5.2 standard.
5. Take a look at NetBeans' output to see how many entities are found with field type GOOD.

There are 2 ways generate the bug:

1. Immediately after a new number is printed in the console, open ObjectDB Explorer, modify an entity's type from GOOD to BAD, save the change, close ObjectDB's connection, and run the project again. Important: do all that until a new number is printed. There is a 1 minute delay set.
2. The same as 1, but keep ObjectDB's connection open. In this case rerunning the project many times doesn't help at all.

Problem: the number of entities with field "type" GOOD found by the the NamedQuery does not correspond with the actual data present in the database. Query: "SELECT b FROM Bug b WHERE b.type = ?1" (param 1 is Bug.Type.GOOD)(type is Embedded(String))(see code)

Problem continuation: I've seen it behaving exactly opposite. So...it was like the query received Type.BAD as parameter.

This happens regardless of Type being an inner class or a standalone class.

Part-time solution: run the project twice after the modification. This doesn't do it for case Error scenario 2. Anyway, this screws up the production environment, because sometimes it doesn't work, but you don't know.

It's the second time when I encounter this bug in 2 different projects.

I would like so much to have this working properly.

Thank you.

BTW...Images are not loading on your website, making it very strange to use.

Thank you for this report.

If you need an immediate solution, please isolate the issue further into a simple minimal console application, as specified in the posting instructions. You should be able to reproduce almost every issue with a simple console application.

If this is not possible, you may create an issue with the current report and web application, but addressing this by our support team is expected to take much more time.

Images in the website work now. Our website may be less stable during the next days due to maintenance, but hopefully much more stable and also faster, when we complete these maintenance operations.

You're welcome.

Well, you're asking me to remove the problem. The problem is that redeploying the application after that kind of usage of Explorer makes JPQL with Enum to don't work properly.

That's why I spent a lot of time to prepare the app and write the instructions, for testing to be easy. The only things you have to do is to download Tomee, add it as a server in NetBeans (2-3 clicks) (http://youtu.be/K8YGK7GrPrY?t=1m15s, open the project in NetBeans and click on run button. That's it.

Anyway...it's just a NamedQuery that is executed by an EntityManager. That's all.

I would really appreciate a fix for this, because it's holding back my team.

Thanks again.

> Well, you're asking me to remove the problem. The problem is that redeploying the application after that kind of usage of Explorer makes JPQL with Enum to don't work properly.

You should probably be able to have the same effect with a console application.

If not, just avoid editing enum values in the Explorer until this is solved. I think that editing enum values is a feature that was added / fixed recently, and possibly has side effects, so you may want to avoid it.

Unfortunately we cannot provide same day fixes for issues that are not demonstrated with either a simple console application or by a simple activity in the Explorer. We understand that it is easier for users that develop web application to post web applications as examples, but since it requires considerably more time from us, it could only be processed in the slower issue tracking route. Thank you for your understanding.

Maybe you can even demonstrate the issue without any application.

What happens when you run that JPQL query in the Explorer? In another Explorer?

Try to bring the issue to its simplest form.

It doesn't seem to happen by executing the query in Explorer.

But, again, the problem is when the project is redeployed, so maybe it's something with the way classes are "added" into the db by ObjectDB.

Moreover, I've seen the error happening not just when I edit an enum(String) field, but when I edit anything of that entity. It doesn't matter what. The moment I touch it, it happens the same, as in the previous scenarios.

I have attached the console maven app. The interesting part is that I couldn't reproduce the error with it. I got it just once, but then it didn't happen anymore. I fixed that one with a server(ODB) restart. This doesn't help too much, because deploying in container seems to be a necessary step. Maybe this gives you more ideas about what might be.

Attempt to run the web application at #1 above failed with many exceptions that indicate that ObjectDB is not found. Looking at the pom.xml file, it seems that ObjectDB is not referenced. Maybe you installed ObjectDB within Tomcat, and maybe I missed something in your instructions, but this demonstrates one of the problems with web applications that users upload, they almost never work out of the box.

Please try to proceed in the direction that you started at #6 above. Since you saw the problem within a console application, but you just don't know yet how to reproduce it, try to find a way to repeat it consistently.

Another thing that you can check is running the Explorer with your classes in the classpath. It may make a difference and serve as a workaround.

Thanks for trying.

Yes, sorry. I forgot that I have ObjectDB in Tomee (not Tomcat). Anyway, just add it in pom.xml.

I look forward for news after you reproduce the problem with the web app.

I managed to reproduce a similar situation by changing the order of the values in the enum, i.e. by first using enum Type { BAD, GOOD } and then using enum Type { GOOD, BAD }.

This is strictly forbidden when storing enum values using ordinal (i.e. you must preserve the order of the values, since these ordinal numbers are stored in the database).

Apparently the files that you sent at #1 above mismatch:

1. the web application includes Type { GOOD, BAD }.
2. the odb file includes Type { BAD, GOOD }, probably because of an older version of the enum that was used previously.

So apparently this problem has nothing to do with the web application and redeployment and / or with the Explorer (just that when you use the Explorer with no classes in the classpath, the Explorer uses the schema as defined in the odb file).

Please try to remember if you might have changed your enum, and also try your test with a clean odb file, when using the same order of values in the enum all the way.

See also the warning (regarding using enum types) in the manual.

I didn't change the enum and I don't use @Ordinal. That's the reason I use them as StringS. Anyway, none of my cases happen because of touching the enum. I didn't do that neither. 

If there is that difference, then there is something wrong with how enums are handled by ObjectDB. Maybe you've just found the bug.

Maybe that's why enums in JPQL work exactly opposite sometimes, because ObjectDB disturbs the order.

Anyway, why would the order matter when enums are stored as strings?

I didn't change the order in the enum class, but that should be allowed anyway, because that's the point of using them as strings. It seems that they work as @Ordinal if that error happens.

Moreover, it's definitely not because of me that db file and enum class order don't match. The only ones that touched them are ObjectDB and Explorer, so maybe it's something fishy there.

More feedback. The third case that triggers the problem, which says the problem also.

Repeat case 1 but don't modify anything. Just open and close the DB in Explorer. (Follow all the steps, but don't modify.) Just by doing this, it seems that the problem appears. So maybe Explorer disturbs something when connects, or there is a problem because Explorer doesn't have the actual classes when opening the DB (so it might interpret and modify them wrongly - or they might be a bug in saving classes inside the db), while the webapp does always have the classes.

As I can understand, without knowing internal ObjectDB details, it might be something fishy with how enums are handled.

I can do whatever I want with the application, as long as I avoid Explorer, without having any problem. That's the main point.

That's a real pain. In the first app I encountered this I had to remove @Enumerated with Long, and add ids for each Enum in my logic, because using @Ordinal is not proper for long term, when you have to add/remove options.

I hope the problem can be found, so I don't have to modify this second project, because this is much larger, so it would require a lot of pain.

Thanks again for your support. I hope I explained it well enough.

I found the solution. So, let me state again the 3 bug scenarios, then I'll point the solution:

1. Immediately after a new number is printed in the console, open ObjectDB Explorer, modify an entity's type from GOOD to BAD, save the change, close ObjectDB's connection, and run the project again. Important: do all that until a new number is printed. There is a 1 minute delay set.
2. The same as 1, but keep ObjectDB's connection open. In this case rerunning the project many times doesn't help at all.
3. The same as 1, but just open and close Explorer.

Solution: after the wrong number is printed (so after you follow case 1/3 (I tested 1 and 3 with this fix)), restart the server through the "restart" feature of the small toolbar icon. After restarting, the next printed number will be proper, without needing to redeploy/run the app the second time (after the wrong numbers are printed). So, restarting ODB server seems to fix the problem.

I hope this gives you more insights.

Thank you.

You are right, it was the Explorer rather than your application that changed the order of the enum values. This is fixed now in version 2.5.3.

Your application was affected because enum query arguments have been passed between the client and the server using their ordinal representation rather than their string representation. This is because when an argument is specified in the client (before query processing on the server side) it is unknown against which field it will be used in the query, and ordinal values are more efficient than string name values. Normally it doesn't matter how arguments are passed, if the same enum definition is used by everyone, but to be on the safe side, starting version 2.5.3 enum query arguments are passed as strings.

Thank you for this important bug report.

Wow. Thank you so much for fixing it.

The world should know what a great support team ObjectDB has.

PS. As a very happy user, I created the wiki page for "objectdb" on stackoverflow (https://stackoverflow.com/tags/objectdb/info) and wrote "Fast Object Database for Java - with JPA/JDO support" as tag pop-up preview.

It's just what you wrote on your website, but now it's easier to access and see by stack users.

Thank you for your help in promoting ObjectDB.