Invalid column index issue with Discriminator

[Lars]

I'm seeing some unusual behavior after converting to Lombok for objects that use the discriminator pattern. Not 100% sure this is Lombok causing this, but it started happening after we added it. We're using JBoss EAP 6.3.0 (also happens with 6.4.0) and Java 1.7.0_80-b15.

What we're seeing is that JPA/Hibernate embeds the ITEM_TYPE_ID parameter in the values, AND specifies it as a parameter. For those of us not having this issue, the value is not "hard-coded" in the values statement. I am the only one in our group having this issue; looks like the others are on EAP 6.2.0.

Wondering if anyone has seen this or has a hunch what might be the issue. 

In our scenario, we have a ClientUser object that extends User.

The ClientUser object:

@Entity
@DiscriminatorValue(com.tcs.constants.ItemTypeConstants.CLIENT_USER_ITEM_TYPE)  // Value of 5
@Table(name="CLIENT_USERS")
@PrimaryKeyJoinColumn(name="ID")
public class ClientUser extends User {
  private static final long serialVersionUID = 1L;


  public ClientUser() {
    super.setItemTypeId(Integer.parseInt(com.tcs.constants.ItemTypeConstants.CLIENT_USER_ITEM_TYPE));
  }
}

The relevant part of our User object:

@Getter @Setter @Audited @Entity
@Table(name="USERS")
@Inheritance(strategy=InheritanceType.JOINED)
@DiscriminatorColumn(name="ITEM_TYPE_ID")
public abstract class User extends AuditedBaseEntity {
  private static final long serialVersionUID = 1L;

  @Id
  @SequenceGenerator(
    name="users_seq",
    sequenceName="USERS_SEQ",
    allocationSize=1
  )
  @GeneratedValue(
    strategy=GenerationType.AUTO,
    generator="users_seq"
  )
  @Column(
    name="ID",
    updatable=false,
    nullable=false
  )
  private Long id = null;


  @Column(name="ITEM_TYPE_ID")
  private Integer itemTypeId;
...

Here's a log output for a failure:

13:58:10,467 INFO  [stdout] (http-mini-lars.local/10.13.13.67:8080-1) Hibernate:
13:58:10,467 INFO  [stdout] (http-mini-lars.local/10.13.13.67:8080-1)     insert  
13:58:10,467 INFO  [stdout] (http-mini-lars.local/10.13.13.67:8080-1)     into
13:58:10,467 INFO  [stdout] (http-mini-lars.local/10.13.13.67:8080-1)         USERS
13:58:10,468 INFO  [stdout] (http-mini-lars.local/10.13.13.67:8080-1)         (VERSION, CREATED_BY, CREATED_DATE, DELETED_DATE, LAST_UPDATE_BY, LAST_UPDATE_DATE, ITEM_TYPE_ID, LAST_LOGIN_DATE, PASSWORD_HASH, USER_NAME, ID)  
13:58:10,468 INFO  [stdout] (http-mini-lars.local/10.13.13.67:8080-1)     values
13:58:10,468 INFO  [stdout] (http-mini-lars.local/10.13.13.67:8080-1)         (?, ?, ?, ?, ?, ?, '5', ?, ?, ?, ?)
13:58:10,469 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [1] as [INTEGER] - 0
13:58:10,469 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [2] as [BIGINT] - <null>
13:58:10,469 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [3] as [TIMESTAMP] - Thu Oct 08 13:58:10 CDT 2015
13:58:10,469 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [4] as [TIMESTAMP] - <null>
13:58:10,470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [5] as [BIGINT] - <null>
13:58:10,470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [6] as [TIMESTAMP] - <null>
13:58:10,470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [7] as [INTEGER] - 5
13:58:10,470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [8] as [TIMESTAMP] - <null>
13:58:10,471 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [9] as [VARCHAR] - 1000:75e460866b59cc6ee9437dbd47e16513ad2a394bcff73263:eb5cc68016d81811124800e853a5c331bb3b24f0a2a697b0
13:58:10,471 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [10] as [VARCHAR] - t0@tcs.com
13:58:10,471 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (http-mini-lars.local/10.13.13.67:8080-1) binding parameter [11] as [BIGINT] - 193
13:58:10,471 INFO  [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (http-mini-lars.local/10.13.13.67:8080-1) HHH000010: On release of batch it still contained JDBC statements
13:58:10,473 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-mini-lars.local/10.13.13.67:8080-1) SQL Error: 17003, SQLState: 99999
13:58:10,474 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-mini-lars.local/10.13.13.67:8080-1) Invalid column index

Looking for clues...

And thanks for viewing this.

[Martin Grajcar]

From what I know how lombok works, it can unprobably be the culprit. Either it generates the setter (AFAIK only a single setter is relevant) and it compiles or it generates nothing and it doesn't compile. You seem to use field binding rather than accessors binding and this makes lombok-related problems even less likely. I'd simply try to simplify the example by dropping everything unnecessary (make a copy of the class or two, rename and minimize).

What we're seeing is that JPA/Hibernate embeds the ITEM_TYPE_ID parameter in the values, AND specifies it as a parameter.

What I'm seeing is you specifying both
@DiscriminatorValue(com.tcs.constants.ItemTypeConstants.CLIENT_USER_ITEM_TYPE)
and

@Column(name="ITEM_TYPE_ID") private Integer itemTypeId;

which is logically redundant:

• When starting with your object, the information is present in its class already.
  
• When starting with a Hibernate proxy, it's their problem (Hibernate created it, so Hibernate must care).
  

I may be missing something, but to me it looks like you're having the column twice (and Hibernate has no good handling for such errors, so everything's possible). It might be required (and maybe even the constructor using CLIENT_USER_ITEM_TYPE again might be required), but to me (with my limited knowledge) it makes little sense.

[Lars]

Thanks for reviewing. 

I'll double check those associations, but what's odd is that it worked fine until we Lombok-ed the project. I agree it doesn't make sense, but with the timing, you never know. Wondered if anyone else experienced similar issues.