It's possible to define enumerations in JPA using either
@Enumerated(EnumType.ORDINAL)
or
@Enumerated(EnumType.STRING)
I wonder what are advantages and disadvantages of those two definitions?
I heard that ORDINAL performs better (is faster) than STRING with EclipseLink.
Is that true?
This is a good question. In the past I used String but today my preference is to use Ordinal.
The main disadvantage for the String is for the DBAs. With the String they have no idea what are the possible values of the column, because this information is in the application code. The DBA only can have some idea about the possible values grouping the existent information on the table, but he will never be sure about the other possible values until the application insert them on the table.
In the Ordinal you have the same problem above. But my preference for Ordinal came to a solution to the DBA problem that seems natural to the database. You can create a new table to show the possible values of the Enumerator on database, with a foreign key between the column (ordinal enum value) and this new table. This strategy is described and implemented here.
About the problem that someone could reorder the Enumerator and break the system, a simple unit test can deal with this problem and guarantee that no one will reorder them without a very good error. The same idea is valid on renaming the Enumerator. So, renaming (on String) or reorder (on Ordinal) accidentally it is not really a strong argument against String or Ordinal approach.
By the way, for my perspective the developers have more necessity to rename than reorder an Enumerator, so I count this as one more positive point to use Ordinal.
So, with this extra table approach, you solve the main problem of the Ordinal (now, is readable) and the information will occupy less space on the database (and your DBA will be happy).
Lots of good advice here, but I just wanted to add something I didn't see yet:
Regardless of the solution you choose, don't forget to add a big fat warning at the top of your enum class saying which should be used. Hopefully other developers will see you've done this and use the same method for saving the enum.
I would prefer EnumType.STRING. A disadvantage of EnumType.ORDINAL is the effect of time and the desire to keep enums in a logical order. With EnumType.ORDINAL any new enum elements must be added to the end of the list or you will accidentally change the meaning of all your records. please check this link: https://tomee.apache.org/examples-trunk/jpa-enumerated/
I would throw in a third possibility: Use explicit mapping via AttributeConverter. This way you get rid of the problem with changing order for ORDINAL and with refactoring names for STRING. This way you can use meaningful enum values with compact and robust storage. For example I have an enum with values "EXPORT" and "IMPORT" which are stored as "E" and "I". If I one day decided to refactor them to "EXPORT_TYPE" and "IMPORT_TYPE", JPA storage is unaffected.