Eclipse Community Forums: EclipseLink » EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3

Home » Eclipse Projects » EclipseLink » EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3(In my migrated project the DTYPE column is not being populated by EclipseLink anymore)

Show: Today's Messages :: Show Polls :: Message Navigator

EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3 [message #1859352]

Thu, 01 June 2023 17:11

Manuel Lemcke

Messages: 4
Registered: June 2023

Junior Member

Hello,

I migrated a web application from JavaEE to JakartaEE 9. In the process I also updated EclipseLink from 2.7.3 to 3.0.0 (and later 3.0.3).

In my data model I have 2 base classes from which some other classes inherit:
ConditionConfigBase and ActionConfigBase:

@Entity
@Table(name = "ActionBase")
@Inheritance(strategy = InheritanceType.JOINED)
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "classDiscriminator")
// additional Jackson @JsonSubTypes Annotations for JSON Serialization
public abstract class ActionConfigBase implements Serializable { // ... }

@Entity
@Table(name = "ConditionBase")
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(discriminatorType = DiscriminatorType.STRING, name = "DTYPE", length=4000)
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "classDiscriminator")
@JsonSubTypes({
    @JsonSubTypes.Type(value = IndexConditionConfig.class, name = "IndexConditionConfig"),
    @JsonSubTypes.Type(value = MaskConditionConfig.class, name = "MaskConditionConfig"),
    @JsonSubTypes.Type(value = LocationConditionConfig.class, name = "LocationConditionConfig")
})
public abstract class ConditionConfigBase implements Serializable { //... }

// a inheriting class:
@Entity
@Table(name = "LocationCondition")
public class LocationConditionConfig extends ConditionConfigBase implements Serializable { // ... }

//2nd base class
@Entity
@Table(name = "ActionBase")
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class ActionConfigBase implements Serializable { //... }

My tables look like this (simplified)

CREATE TABLE [ep2].[ConditionBase](
	[Id] [uniqueidentifier] NOT NULL,
	[Name] [nvarchar](4000) NULL,
	[Description] [nvarchar](max) NULL
	[DTYPE] [nvarchar](512) NULL 
--DTYPE is the EL default column name for the discrimnator column
)
-- A inheriting entity:
CREATE TABLE [ep2].[LocationCondition](
	[Path] [nvarchar](4000) NOT NULL,
	[CheckReferences] [bit] NOT NULL,
	[EndLevel] [int] NOT NULL,
	[Id] [uniqueidentifier] NOT NULL
)

CREATE TABLE [ep2].[ActionBase](
	[Id] [uniqueidentifier] NOT NULL,
	[Name] [nvarchar](4000) NULL,
	[Description] [nvarchar](max) NULL,
	[Position] [int] NULL,
	[ActionGroupId] [uniqueidentifier] NULL,
	[DTYPE] [nvarchar](512) NULL
)

With these annotations everything worked fine in 2.7.3.

In 3.0.0 and 3.0.3 though, the data is read correctly from the database BUT when EclipseLink is writing into the Database it is not populating the DTYPE column anymore. So after EL wrote the first time from the migrated application it can't read the data anymore since it's missing the DTYPE values.

I tried adding

@DiscriminatorColumn(discriminatorType = DiscriminatorType.STRING, name = "DTYPE")

to the base classes and e.g.

@DiscriminatorValue("LocationConditionConfig")

to the specific classes - with no effect.

I also updated my persistence.xml so it matches the one from https://www.eclipse.org/forums/index.php/t/1110015/

And of course I replaced the javax imports with jakarta imports (so the current @Inheritance Annotation is from the package jakarta.persistence).

What am I missing?

Report message to a moderator

Re: EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3 [message #1859408 is a reply to message #1859352]

Mon, 05 June 2023 17:10

Chris Delahunt

Messages: 60
Registered: December 2021

Member

Unfortunately I don't have a comparible app handy to run to get a sense of what you might need to look for, or what could be going wrong, but what I'd suggest is turn logging on to FINEST or ALL as it should give some hints and clues on what is being picked up during deployment for your entities. You might want to run the old app and compare the start up/deployment logs to the new one since it might be easier to spot differences first, and then go looking for any warnings/messages to do with the specific entities involved in this inheritance graph. FINEST/ALL logging should also show what it is doing on insert and maybe why it isn't writing out the discriminator type. Maybe show a specific class being written out and the logs for that section if you need help determine what the logs might mean or indicate (if anything).

Was the tables initially generated with EclipseLink? I am just wondering on why you have length=4000 defined in the ConditionConfigBase DTABLE annotation, but the table is using [DTYPE] [nvarchar](512) NULL. Could there have been some other mapping defining this column in the javax application?

Report message to a moderator

Re: EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3 [message #1859421 is a reply to message #1859408]

Tue, 06 June 2023 12:50

Manuel Lemcke

Messages: 4
Registered: June 2023

Junior Member

Thank you for your response!

To adress your questions:
No, the tables weren't generated by EclipseLink. (at it's start the project was developed "database first").
I think I will let it generate tables and compare them to the current state.

Length=4000 was a mistake. Before I set it to that value , the length parameter wasnt defined at all, with the same behaviour. I changed it to the correct value of 512 now but that doesn't change the behaviour.

I also have logs from a old version of the app and from the new version now.

What I can see is that in the old version EL inserted into ConditionBase and then into IndexCondition directly afterwards:


[EL Finer]: transaction: 2023-06-06 14:42:22.15--UnitOfWork(989564952)--Thread(Thread[http-nio-9070-exec-1,5,main])--begin unit of work commit
[EL Finest]: query: 2023-06-06 14:42:22.154--UnitOfWork(989564952)--Thread(Thread[http-nio-9070-exec-1,5,main])--Execute query UpdateObjectQuery(de.smiss.procelo.config.model.Rule[ id=E5BF5F36-AD52-4F73-98F3-F26D1FE7BD8D ])
[EL Finest]: query: 2023-06-06 14:42:22.155--UnitOfWork(989564952)--Thread(Thread[http-nio-9070-exec-1,5,main])--Execute query InsertObjectQuery(de.smiss.procelo.config.model.IndexCondition[ id=5DC0D239-EDCF-43DE-80E7-2D4A95900CC5 ])
[EL Finest]: connection: 2023-06-06 14:42:22.155--ServerSession(1605552131)--Connection(2140169581)--Thread(Thread[http-nio-9070-exec-1,5,main])--Connection acquired from connection pool [default].
[EL Finer]: transaction: 2023-06-06 14:42:22.155--ClientSession(1617770308)--Connection(2140169581)--Thread(Thread[http-nio-9070-exec-1,5,main])--begin transaction
[EL Finest]: connection: 2023-06-06 14:42:22.155--ClientSession(1617770308)--Thread(Thread[http-nio-9070-exec-1,5,main])--reconnecting to external connection pool
[EL Fine]: sql: 2023-06-06 14:42:22.156--ClientSession(1617770308)--Connection(274602527)--Thread(Thread[http-nio-9070-exec-1,5,main])--INSERT INTO ep2.ConditionBase (Id, Description, IsActive, Name, DTYPE) VALUES (?, ?, ?, ?, ?)
	bind => [5DC0D239-EDCF-43DE-80E7-2D4A95900CC5, null, true, A, IndexConditionConfig]
[EL Fine]: sql: 2023-06-06 14:42:22.163--ClientSession(1617770308)--Connection(274602527)--Thread(Thread[http-nio-9070-exec-1,5,main])--INSERT INTO ep2.IndexCondition (IndexLineName, IndexLineValues, Id) VALUES (?, ?, ?)
	bind => [B, C, 5DC0D239-EDCF-43DE-80E7-2D4A95900CC5]
[EL Finest]: query: 2023-06-06 14:42:22.165--UnitOfWork(989564952)--Thread(Thread[http-nio-9070-exec-1,5,main])--Execute query DataModifyQuery()
[EL Fine]: sql: 2023-06-06 14:42:22.166--ClientSession(1617770308)--Connection(274602527)--Thread(Thread[http-nio-9070-exec-1,5,main])--UPDATE ep2.ConditionBase SET RuleId = ? WHERE (Id = ?)
	bind => [E5BF5F36-AD52-4F73-98F3-F26D1FE7BD8D, 5DC0D239-EDCF-43DE-80E7-2D4A95900CC5]
[EL Finer]: transaction: 2023-06-06 14:42:22.168--ClientSession(1617770308)--Connection(274602527)--Thread(Thread[http-nio-9070-exec-1,5,main])--commit transaction
[EL Finest]: connection: 2023-06-06 14:42:22.17--ServerSession(1605552131)--Connection(2140169581)--Thread(Thread[http-nio-9070-exec-1,5,main])--Connection released to connection pool [default].
[EL Finer]: transaction: 2023-06-06 14:42:22.171--UnitOfWork(989564952)--Thread(Thread[http-nio-9070-exec-1,5,main])--end unit of work commit
[EL Finer]: transaction: 2023-06-06 14:42:22.171--UnitOfWork(989564952)--Thread(Thread[http-nio-9070-exec-1,5,main])--resume unit of work
[EL Finer]: transaction: 2023-06-06 14:42:22.171--UnitOfWork(989564952)--Thread(Thread[http-nio-9070-exec-1,5,main])--release unit of work
[EL Finer]: connection: 2023-06-06 14:42:22.171--ClientSession(1617770308)--Thread(Thread[http-nio-9070-exec-1,5,main])--client released

but in the new version it inserts with DTYPE=null and doesn't do a second insert:

[EL Finer]: transaction: 2023-06-06 14:05:59.855--UnitOfWork(856290401)--Thread(Thread[http-nio-9070-exec-10,5,main])--begin unit of work commit
[EL Finest]: query: 2023-06-06 14:05:59.858--UnitOfWork(856290401)--Thread(Thread[http-nio-9070-exec-10,5,main])--Execute query UpdateObjectQuery(de.smiss.procelo.config.model.Rule[ id=007B0477-5803-4C64-ACDA-C35C97EB3942 ])
[EL Finest]: query: 2023-06-06 14:05:59.859--UnitOfWork(856290401)--Thread(Thread[http-nio-9070-exec-10,5,main])--Execute query InsertObjectQuery(de.smiss.procelo.config.model.IndexCondition[ id=495B5D9B-8580-45D9-AE40-0AC3805543EF ])
[EL Finest]: connection: 2023-06-06 14:05:59.859--ServerSession(2013549959)--Connection(1968667715)--Thread(Thread[http-nio-9070-exec-10,5,main])--Connection acquired from connection pool [default].
[EL Finer]: transaction: 2023-06-06 14:05:59.859--ClientSession(931318934)--Connection(1968667715)--Thread(Thread[http-nio-9070-exec-10,5,main])--begin transaction
[EL Finest]: connection: 2023-06-06 14:05:59.859--ClientSession(931318934)--Connection(1968667715)--Thread(Thread[http-nio-9070-exec-10,5,main])--reconnecting to external connection pool
[EL Fine]: sql: 2023-06-06 14:05:59.86--ClientSession(931318934)--Connection(801754115)--Thread(Thread[http-nio-9070-exec-10,5,main])--
INSERT INTO ep2.ConditionBase (RuleId, Id, Description, IsActive, Name, DTYPE) VALUES (?, ?, ?, ?, ?, ?)
	bind => [007B0477-5803-4C64-ACDA-C35C97EB3942, 495B5D9B-8580-45D9-AE40-0AC3805543EF, null, true, A, null]
[EL Finer]: transaction: 2023-06-06 14:05:59.862--ClientSession(931318934)--Connection(801754115)--Thread(Thread[http-nio-9070-exec-10,5,main])--commit transaction
[EL Finest]: connection: 2023-06-06 14:05:59.864--ServerSession(2013549959)--Connection(1968667715)--Thread(Thread[http-nio-9070-exec-10,5,main])--Connection released to connection pool [default].
[EL Finer]: transaction: 2023-06-06 14:05:59.865--UnitOfWork(856290401)--Thread(Thread[http-nio-9070-exec-10,5,main])--end unit of work commit
[EL Finer]: transaction: 2023-06-06 14:05:59.865--UnitOfWork(856290401)--Thread(Thread[http-nio-9070-exec-10,5,main])--resume unit of work
[EL Finer]: transaction: 2023-06-06 14:05:59.865--UnitOfWork(856290401)--Thread(Thread[http-nio-9070-exec-10,5,main])--release unit of work
[EL Finer]: connection: 2023-06-06 14:05:59.865--ClientSession(931318934)--Thread(Thread[http-nio-9070-exec-10,5,main])--client released

The log configuration is:

   
<properties>
  <property name="eclipselink.logging.file" value="eclipseLink.log"/>
   <property name="eclipselink.logging.level" value="FINEST"/>
  <property name="eclipselink.logging.parameters" value="true"/>          
</properties>

In the meantime I also updated to EclipseLink 4.0.1 because I saw some log statements like "The java.lang.Object class was compiled with an unsupported JDK. Report this error to the EclipseLink open source project.
java.lang.IllegalArgumentException: Unsupported class file major version 61".

Maybe it's also relevant how the code that should trigger the INSERTs looks.

Most of the time this method is called via JAX-RS (Jersey). RuleConfig contains List<ActionBaseConfig> and List<ConditionBaseConfig>.

    @PUT
    @Path("{id}")
    @Consumes({MediaType.APPLICATION_JSON})
    public void edit(@PathParam("id") String id, RuleConfig entity) {
        super.edit(entity);
    }

//method in generic superclass:
    public void edit(T entity) {
        getEntityManager().merge(entity);
    }

[Updated on: Tue, 06 June 2023 14:22]

Report message to a moderator

Re: EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3 [message #1859422 is a reply to message #1859421]

Tue, 06 June 2023 14:59

Chris Delahunt

Messages: 60
Registered: December 2021

Member

"Unsupported class file major version 61" indicates an issue with the JDK being used, with classes compiled from Java 17 being used on an earlier JDK runtime. This can crop up though on ASM libraries: https://bugs.eclipse.org/bugs/show_bug.cgi?id=551398 so moving to the latest version is ideal.

IndexCondition in your log isn't one of the entities you've shown, but assuming it is mapped similar to LocationConditionConfig.. there isn't enough to tell what could be going wrong. If I were to guess, I'd guess that some annotations were not converted to Jakarta persistence causing some classes annotations to be missed/ignored. Something like a missing Entity annotation on IndexCondition would cause this behavior.

Take a look at the logs during deployment - they should state each entity being processed and what it is finding for annotations, config and mappings within each. Differences between the two versions might help tell why the IndexCondition seems to be treated as a subclass of ConditionConfigBase but not as an Entity itself.

Report message to a moderator

Re: EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3 [message #1859430 is a reply to message #1859422]

Wed, 07 June 2023 12:05

Manuel Lemcke

Messages: 4
Registered: June 2023

Junior Member

Yes, all conditions are mapped in the same way to the base class / root-table. (Actions are mapped similarily but there are much more of them so i use conditions as example.) Sorry for using an entity I didn't state earlier.

For the sake of completeness ( I also keep the PK and FK statements this time):

CREATE TABLE [ep2].[IndexCondition](
	[IndexLineName] [nvarchar](128) NULL,
	[IndexLineValues] [nvarchar](4000) NULL,
	[Id] [uniqueidentifier] NOT NULL,
 CONSTRAINT [PK_IndexCondition] PRIMARY KEY CLUSTERED 
(
	[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

ALTER TABLE [ep2].[IndexCondition] ADD  CONSTRAINT [DF_IndexCondition_Id]  DEFAULT (newid()) FOR [Id]

ALTER TABLE [ep2].[IndexCondition]  WITH CHECK ADD  CONSTRAINT [FK_IndexCondition_ConditionBase] FOREIGN KEY([Id])
REFERENCES [ep2].[ConditionBase] ([Id])

With the class looking like this:

package de.smiss.procelo.config.model.conditions;

import de.smiss.procelo.config.model.ConditionConfigBase;
import java.io.Serializable;
import jakarta.persistence.Column;
import jakarta.persistence.DiscriminatorValue;
import jakarta.persistence.Entity;
import jakarta.persistence.Table;
import jakarta.validation.constraints.Size;

@Entity
@Table(name = "IndexCondition")
@DiscriminatorValue("IndexConditionConfig")
public class IndexConditionConfig extends ConditionConfigBase implements Serializable { //...

Quote:

If I were to guess, I'd guess that some annotations were not converted to Jakarta persistence causing some classes annotations to be missed/ignored. Something like a missing Entity annotation on IndexCondition would cause this behavior.

I checked the imports and searched for javax over the projects and only found Jakarta annotations. I'm thankful for every hint though, so I appreciate guesses :-).

An additional thing that came to my mind: originally, the Id column was NOT NULL but I changed it to NULL so I can analyse the issue better.

And: can the problem have to do with the fact that the non-abstract classes like IndexCondition are in a sub-package of ConditionBase's package?

I'm currently comparing the deployment/initialization logs. At the moment I don't see big differences but some log statements that are in both logs surprise me. For example there are a lot of statments that say it defaults to something despite having an annotation (with the default value like Id as PK, the classes simple name despite @DiscriminatorValue etc.).

[EL Config]: metadata: 2023-06-06 14:31:11.956--ServerSession(1605552131)--Thread(Thread[Thread-9,5,main])--The alias name for the entity class [class de.smiss.procelo.config.model.conditions.IndexConditionConfig] is being defaulted to: IndexConditionConfig.
[EL Config]: metadata: 2023-06-06 14:31:11.956--ServerSession(1605552131)--Thread(Thread[Thread-9,5,main])--The primary key column name for the inheritance class [class de.smiss.procelo.config.model.conditions.IndexConditionConfig] is being defaulted to: Id.
[EL Config]: metadata: 2023-06-06 14:31:11.957--ServerSession(1605552131)--Thread(Thread[Thread-9,5,main])--The foreign key column name for the inheritance class [de.smiss.procelo.config.model.conditions.IndexConditionConfig] is being defaulted to: Id

while Id is explicitly set by the @Id annotation:

package de.smiss.procelo.config.model;

import com.fasterxml.jackson.annotation.JsonSubTypes;
import com.fasterxml.jackson.annotation.JsonTypeInfo;
import de.smiss.procelo.config.model.conditions.IndexConditionConfig;
import de.smiss.procelo.config.model.conditions.LocationConditionConfig;
import de.smiss.procelo.config.model.conditions.MaskConditionConfig;
import java.io.Serializable;
import jakarta.persistence.Basic;
import jakarta.persistence.Column;
import jakarta.persistence.DiscriminatorColumn;
import jakarta.persistence.DiscriminatorValue;
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.Inheritance;
import jakarta.persistence.InheritanceType;
import jakarta.persistence.Table;
import jakarta.validation.constraints.NotNull;
import jakarta.validation.constraints.Size;

@Inheritance(strategy = InheritanceType.JOINED)
@Entity
@Table(name = "ConditionBase")
@DiscriminatorColumn(discriminatorType = jakarta.persistence.DiscriminatorType.STRING, name = "DTYPE", length = 512)
@DiscriminatorValue(value = "ConditionConfigBase")
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "classDiscriminator")
@JsonSubTypes({
    @JsonSubTypes.Type(value = IndexConditionConfig.class, name = "IndexConditionConfig"),
    @JsonSubTypes.Type(value = MaskConditionConfig.class, name = "MaskConditionConfig"),
    @JsonSubTypes.Type(value = LocationConditionConfig.class, name = "LocationConditionConfig")
})
public abstract class ConditionConfigBase implements Serializable {

    @Id
    @Basic(optional = false)
    @NotNull
    @Size(min = 1, max = 36)
    @Column(name = "Id")
    public String id;

[Updated on: Wed, 07 June 2023 12:46]

Report message to a moderator

Re: EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3 [message #1859561 is a reply to message #1859430]

Thu, 15 June 2023 10:55

Manuel Lemcke

Messages: 4
Registered: June 2023

Junior Member

I changed the Inheritance configuration from Annotations to XML: EclipseLink is still not writing DTYPE / 2nd Table.

Report message to a moderator

Re: EL 3.0.x not writing into DiscriminatorColumn after migration from 2.7.3 [message #1859565 is a reply to message #1859561]

Thu, 15 June 2023 14:58

Chris Delahunt

Messages: 60
Registered: December 2021

Member

The alias name for the entity class refers to the JPA entity name, what you use in JPQL query strings. The log entries mentioning ID for IndexConditionConfig refer to the IndexConditionConfig table and its primary key; this isn't defined in your entity (or isn't in most cases), and is what JPA will use to link it to the root ConditionBase table. The entity instance itself will use the same property within the ConditionBase as its ID, so the ConditionBase ID column is also what every FK will reference still when referencing a IndexConditionConfig.

What you've shown is that IndexConditionConfig is getting noticed as being part of the inheritance graph. You haven't shown any discriminator column or value annotations being processed, but I assume you'd notice the difference in your apps logs if there was one. All I can think of next is to reproduce it in a debugger and see if when you persist a IndexConditionConfig (or what ever subclass shows the issue), if the internals of EclipseLink pull up a descriptor for that class, or pull up one for the root class. Sessions key the descriptor in a hashmap based on the Class, so if it isn't being found, it could be a class loading issue.

Report message to a moderator

Previous Topic:	XMLIDRef behaviour changed from 3.0.3 to 4.0
Next Topic:	EclipseLink migration 2.1.3 -> 2.7.12

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Jan 23 01:56:13 GMT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter