2

My entity-class hierarchy starts with a MappedSuperclass providing a "status" attribute and declaring a query redirector in case of "delete":

@MappedSuperclass
@AdditionalCriteria(value = "this.entityStatus <> 'DELETED'")
@QueryRedirectors(delete = LogicDeleteInterceptor.class)
public abstract class AStatusEntity
{
    private String entityStatus;
    ...
}

Then a User entity, deriving from AStatusEntity, declaring the JOINED strategy for further subclasses:

@Entity
@Table(name = "USERS")
@Inheritance(strategy = InheritanceType.JOINED)
public class User extends AStatusEntity
{
    ...
}

And finally a UserProfile entity, deriving from User:

@Entity
@Table(name = "USER_PROFILE")
public class UserProfile extends User
{
    ...
}

The User entity properly inherits the delete redirector, so that it gets soft-deleted (status = "DELETED") when I call "remove" on it.

For UserProfile things are different: when I call "remove" on a UserProfile entity instance, the delete redirector is ignored (any breakpoint in the redirector body is ignored during the debug) and EclipseLink trys to hard delete the UserProfile row on the DB and the User row too (JOINED strategy => two different tables).

I have tried applying the redirector on the UserProfile class itself, like this:

@Entity
@Table(name = "USER_PROFILE")
@QueryRedirectors(delete = LogicDeleteInterceptor.class)
public class UserProfile extends User
{
    ...
}

But it is still ignored and a hard-delete is attempted.

What am I missing?...

ENVIRONMENT: EclipseLink version is 2.6.3 | Oracle JVM 1.8.0_91 x64 | execution environment: Apache Karaf OSGi container version 4.0.4 |OS: Ubuntu Linux x86_64

  • If you turn on logging to finest, you should see a "metadata_warning_ignore_inheritance_subclass_default_redirectors" type warning when you have the redirector on the subclass. I believe it maybe a bug, but the code may assume the parent's redirectors are picked up by the subclasses when in your case they are not. If you are able to debug, some break points in EclipseLink code before the redirector is called should confirm it is null in the subclass and a bug should be filed. A workaround would be to add the redirectors in a customizer on all child descriptors – Chris Jul 19 '16 at 14:39
  • Hi @Chris, I did a debug session as you suggested: the following chain `org.eclipse.persistence.queries.DatabaseQuery.getRedirectorForQuery() => org.eclipse.persistence.queries.DeleteObjectQuery.getDefaultRedirector() => org.eclipse.persistence.descriptors.ClassDescriptor.getDefaultDeleteObjectQueryRedirector()` clearly shows that the redirector is not null in the descriptor for the "User" object while it **is** null for "UserProfile". So do you think I should file a bug? Thanks. – Roberto Pierpaoli Jul 21 '16 at 16:46

0 Answers0