Greetings everyone,
Since I don't know how to describe the problem in a concise way, I will instead post code snippets to reproduce the problem.
Code:
@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public class SubDocument implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@AccessType(value = "field")
private Long id;
public Long getID() {
return id;
}
}
@Entity
public class Order extends SubDocument {
@Temporal(TemporalType.DATE)
@AccessType(value="field")
private Date date;
public Date getDate() {
return date;
}
public void setDate(Date date) {
this.date = date;
}
}
@Entity
public class Quotation extends SubDocument {
@Temporal(TemporalType.DATE)
@AccessType(value="field")
private Date date;
public Date getDate() {
return date;
}
public void setDate(Date date) {
this.date = date;
}
}
@Entity
public class MasterDocument implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@AccessType(value = "field")
private Long id;
@ManyToOne
@AccessType(value = "field")
private SubDocument subDocument;
public Long getID() {
return id;
}
public SubDocument getSubDocument() {
return subDocument;
}
public void setSubDocument(SubDocument subDocument) {
this.SubDocument = subDocument;
}
}
Now, if you try to query in HQL like this,
Code:
SELECT subDocument.date
FROM MasterDocument AS masterDocument
LEFT JOIN masterDocument.subDocument AS subDocument
WHERE subDocument.date = :date
the results are invalid. Looking at the generated SQL points to the problem. It seems that every possible child class of SubDocument will be left outer joined, but the where clause will only verify on the first join table that does have the column "date". It's then missing on the other ones. The behavior is also inconsistent between different installations since the left outer join are not ordered in any particular way.
So my question is this, is there a bug in the SQL conversion? I know that the code design in this case is not something that would be recommended, but the fact is that HQL does permit this kind of query. I tested this behavior with MSSQL and Derby dialects and both resulted in the invalid result set.
Thank you all for your answers in advance.
N.B. If this was already documented elsewhere, please forgive me. I tried searching in the forums, but since I don't really know how to describe the problem, no satisfactory results where found.
Login
FAQ
Search