I use a list. The list is comprised of a compound primary key which is also used for sorting the list.
The problem is that if I delete an element in the list (key compound),
annotation #OrderColumn generates a request to update a primary key, and the cost rises an exception of type:
[26-05-2011 10:34:18:835] WARN org.hibernate.util.JDBCExceptionReporter - SQL Error: 1062, SQLState: 23000
[26-05-2011 10:34:18:835] ERROR org.hibernate.util.JDBCExceptionReporter -Duplicate entry '10-10' for key 'PRIMARY'
[26-05-2011 10:34:18:835] ERROR org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
Here is the definition of the mapping :
#ManyToMany(cascade=CascadeType.ALL, fetch = FetchType.LAZY)
#JoinTable(name = "chapter_item", joinColumns = { #JoinColumn(name = "chapter_id", nullable = false, updatable = false) }, inverseJoinColumns = { #JoinColumn(name = "item_id", nullable = false, updatable = false) })
#OrderColumn(name="iorder")
public List<Item> getItems() {
return items;
}
Here is the update query where I have a problem:
Hibernate:
update
chapter_item
set
item_id=?
where
chapter_id=?
and iorder=?
I wonder if this is a known bug, and if anyone has a solution?
Regarding #OrderColumn, following documentation is found at http://docs.oracle.com/javaee/6/api/javax/persistence/OrderColumn.html
Specifies a column that is used to maintain the persistent order of a
list. The persistence provider is responsible for maintaining the
order upon retrieval and in the database. The persistence provider is
responsible for updating the ordering upon flushing to the database to
reflect any insertion, deletion, or reordering affecting the list.
So we see that the persistence provider i.e. hibernate is responsible for updating the column named iorder. It is also said that:
The OrderColumn annotation is specified on a OneToMany or ManyToMany
relationship or on an element collection. The OrderColumn annotation
is specified on the side of the relationship that references the
collection that is to be ordered. The order column is not visible as
part of the state of the entity or embeddable class.
Please take note of the sentence that says:
The order column is not visible as part of the state of the entity or
embeddable class.
So, may I suggest you to consider not selecting the column iorder for #OrderColumn since it is a part of your composite key and hibernate is sure to update this value when you delete or insert an element in list (List<Item>).
Hope, this helps.
Maybe one option could be change the order annotation and use:
#ManyToMany(cascade=CascadeType.ALL, fetch = FetchType.LAZY)
#JoinTable(name = "chapter_item", joinColumns = { #JoinColumn(name = "chapter_id", nullable = false, updatable = false) }, inverseJoinColumns = {#JoinColumn(name = "item_id", nullable = false, updatable = false) })
#org.hibernate.annotations.Sort(type = SortType.COMPARATOR, comparator = ItemComparator)
public List<Item> getItems() {
return items;
}
https://dzone.com/articles/sorting-collections-hibernate
Check performance solution because maybe is too slow for big amount of data, and if you can share if was a possible solution would be great to know
Related
I want to use a field in one optional and one mandatory composite foreign key within one entity.
I have three different entities, Team, Person and Shard. Persons belong to a team ManyToOne. Both entities have a ShardID, which is a FK to Shard.
All teams and persons have IDs that are only unique per shard, but they will also only reference the other entities with the same shard ID. Their ShardID is part of their Primary key.
Shard
---
PK ID
UNIQUE Name
Team
---
PK, FK1 ShardID
PK ID
---
FK1 (ShardID -> Shard)
Person
---
PK, FK1, FK2 ShardID
PK ID
FK2 TeamID
---
FK1 (ShardID -> Shard)
FK2 (ShardID, TeamID -> Team)
Additionally, the Person -> Team relationship is optional. A Person may not be member of a Team, and this may change over time.
In trying to model the Person object in JPA, I run into a problem. Obviously, when I model both the ShardID as part of the primary key and as a foreign key column, hibernate gives me the Repeated column in mapping for entity error. I can prevent this using insertable = false, updatable = false:
// This contains the shard_id column
#EmbeddedId
protected PersonId id;
#ManyToOne(optional = true)
#JoinColumns({
#JoinColumn(name = "shard_id", insertable = false, updatable = false),
#JoinColumn(name = "team_id", nullable = true)
})
But I cannot do this because hibernate requires all JoinColumns to have identical settings for insertable and updatable, and I need the ability to add a team to the person later down the line. ShardID will always be present, but TeamID may not be.
How can I achieve this in hibernate JPA ORM? I've browsed the hibernate docs for O/R modeling and can't find a way. I've been looking at table inheritance, but that feels very unnatural and doesn't fix the "optional problem".
This example does not contain my actual data model, but serves as a simplified example.
You can try to use #JoinColumnOrFormula like this:
#JoinColumnOrFormulas({
#JoinColumnOrFormula(formula = #JoinFormula(value = "shard_id", referencedColumnName = "shard_id")),
#JoinColumnOrFormula(column = #JoinColumn(name = "team_id", referencedColumnName = "id", nullable = true))
})
In our Java EE EJB application, we have the following JPA/Hibernate mapping of a class:
#Entity
#Table(name="T")
#TableGenerator( /* all annotation attributes */)
public class T {
#Id
#GeneratedValue(strategy = GenerationType.TABLE)
#Column(name="SEQ_T", nullable = false)
private long seqT;
#OneToMany(
cascade = CascadeType.ALL,
orphanRemoval = true,
mappedBy = "t",
fetch = FetchType.LAZY
)
private List<W> wu;
}
and these are the classes which are in relation with it:
#Entity
#Table(name="W")
#TableGenerator( /* all annotation attributes */)
public class W {
#Id
#GeneratedValue(strategy = GenerationType.TABLE)
#Column(name="SEQ_W", nullable = false)
private long seqW;
#Column(name="SEQ_T", nullable = false)
private long seqT;
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "SEQ_T", insertable = false, updatable = false)
private T t;
#OneToMany(
cascade = CascadeType.ALL,
orphanRemoval = true,
mappedBy = "w",
fetch = FetchType.LAZY
)
private List<WA> wua;
}
#Entity
#Table(name="WA")
#TableGenerator( /* all annotation attributes */)
public class WA {
#Id
#GeneratedValue(strategy = GenerationType.TABLE)
#Column(name="SEQ_W_A", nullable = false)
private long seqWA;
#Column(name="SEQ_W", nullable = false)
private long seqW;
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "SEQ_W", insertable = false, updatable = false)
private W w;
}
Moreover, we have a scheduled job which is executed periodically by TimerService EJB.
First of all, this job must understand if there is something to execute so it performs a native sql query like the following to recover a list of pk from T table according several conditions:
List<Long> seqTs = (List<Long>)em.createNativeQuery("select SEQ_T from T").getResultList();
where em is an instance of EntityManager. The query is not obviously that simple but very complex as it derives from some JOIN and subqueries with other tables.
If the returned list is not empty, then the job can do its work and this JPQL is performed to load the entities it manipulates:
String queryJPQL = "select wu from W wu JOIN FECTCH wu.wua where wu.seqT in :seqTs";
List<Workup> wus = em.createQuery(queryJPQL, W.class)
.setParameter("seqTs", seqTs)
.getResultList();
This query is performed because even if we always need the data in #OneToMany relation, if we set that relation as EAGER then N+1 queries is performed. Instead, with JOIN FETCH a unique query is performed recovering a sort of view and then entities and relations are associated by Hibernate.
Well, the problem is that this exception is raised when .setParameter() is called:
Exception in thread "main" java.lang.IllegalArgumentException: Parameter value element [1] did not match expected type [java.lang.Long (n/a)]
Reading many posts here, and set a breakpoint in Eclipse, I discovered that not a List<Long> is returned from a native query but a List<BigInteger> (according to native type of PK in database), without any ClassCastException or similar. Why this?
So, I guess I should perform something like this before:
List<Long> seqTLong = new ArrayList<Long>();
for(BigInteger seqNative : seqTs)
seqTLong.add(seqNative.longValue());
and pass it to the query.
Anyway, is this the right solution? Is it safe? This because our application supports 3 DB and it is built accordingly in 3 JARs by ANT: Oracle, PostgreSQL and SQL Server.
Can I assume the value of PK is always BigInteger for each DB? In Oracle we use Number(19), in PostgreSQL we use BigInt...I don't remember about SQL Server.
This entities are then passed to DRools and when rules have been applied, this job uses EntityManager to persist data. That's why I need JPA entities to be loaded, otherwise I would get a
Caused by: org.hibernate.PersistentObjectException: detached entity passed to persist
or I would have to call .find() again for each fact modified by DRools and set its attributes by calling getters from the others. Which still causes N+1 queries.
A safer method would be to use Number instead of BigInteger
List<Long> seqTLong = new ArrayList<Long>();
for(Number seqNative : seqTs) {
seqTLong.add(seqNative.longValue());
}
I am using hibernate Reverse Engineering tool to generate pojo's from my database. Say I have two table's A and B in my database and another table ABMap which has two columns A_id and B_id that are foreign keys to table A and B respectively, and the primary key of ABMap is the composite key of A_id and B_id.
Now, when I build my project and generate the pojos, instead of ABMap being generated as a separate entity by hibernate, it is added into the entity A as a Set. Below is the snippet of code generated in entity A,
#ManyToMany(fetch = FetchType.LAZY)
#JoinTable(name = “ABMap”, schema= “myDB”, joinColumns = {
#JoinColumn(name = “A_id”, nullable = false, updatable = false) }, inverseJoinColumns = {
#JoinColumn(name = “B_id”, nullable = false, updatable = false) })
public Set getBs() {
return this.bs;
}
public void setBs(Set bs) {
this.bs = bs;
}
Now the issue here is, using hibernate or Jpa I can do a insert into the ABMap table without actually having an entity of ABMap but I cannot update the same record since the updatable element in #JoinColumn is set to false by hibernate reverse engineering tool. Below is the sql error that occurs when an attempt is made to update the value of B_id.
2014-12-17 13:26:50,639 ERROR (qtp850520326-20) [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] - The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_A_B". The conflict occurred in database "myDB", table "B", column 'B_id'.
How can I set the updatable element in #JoinColumn to true?
I'm not expecting a concrete answer for this question because it's way too complex to explain in detail, just some guidance on where the problem could be.
Im summary, I have an entity Ship, with foreign keys to entities Origin, Destination and Country. I fetch a Ship from the database, then modify other field (date), and then query the database for related Origin, Destination and Country. When I query for Origin and Country, it goes as expected, but when I query for Destination, when executing query.getResultList() , and before the select a from DESTINATION, Hibernate automatically executes update SHIP set ... and it sets all the Ship fields except for IDN_DEST.
Any idea of what could this be happening?
My guess is that since the entity has been modified within the Session, Hibernates somehow things it needs to be updated, but that's all.
For what I've seen, there are no differences in the Ship.java:
// bi-directional many-to-one association
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "IDN_ORIGIN", insertable = false, updatable = false)
private Origin tOrigin;
#Column(name = "IDN_ORIGIN")
private Integer idnOrigin;
// bi-directional many-to-one association
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "IDN_DEST", insertable = false, updatable = false)
private Destination tDest;
#Column(name = "IDN_DEST", updatable = false)
private Integer idnDest;
// bi-directional many-to-one association
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "IDN_COUNTRY", insertable = false, updatable = false)
private Country tCountry;
#Column(name = "IDN_COUNTRY")
private Integer idnCountry;
About your question: Hibernate before a Query.list() perform a dirty check and automatically do a flush() to prevent inconsistent state.
To prevent that change Session.flushMode to COMMIT if you don't want automatic flush, but only at commit time.
About your example, two things:
Why you are not using a getter to get tOrigin, tCountry, tDest?
May you read tOrigin, tCountry, tDest before Ship update?
Tis is happening because when you select a Destination hibernate auto-flushes the session, so the state of the Ship is updated in the database. This means that when you modify other field (date) the ship object is attached to the session.
That should be not done only with Destination as tibtof told when you fetch data from database it creates persistent object and when you modify it hibernate will update it in database when it flushes connection, what you can try is after fetching Origin or Country flush session manually you should get updated data as what happened with 'Destination'.
When implementing composite primary keys in Hibernate or other ORMs there are up to three places where to put the insertable = false, updatable = false in composite primary key constellations that use identifying relationships (FKs that are part of the PK):
Into the composite PK class' #Column annotation (#Embeddable classes only) or
Into the entity class' association #JoinColumn/s annotation or
Into the entity class' redundant PK property's #Column annotation (#IdClass classes only)
The third is the only way to do with #IdClass and JPA 1.0 AFAIK. See http://en.wikibooks.org/wiki/Java_Persistence/Identity_and_Sequencing#Primary_Keys_through_OneToOne_Relationships. I will consider only cases 1. and 2.
Q:
Which way is the preferred place to put the "insertable = false, updatable = false" to generally?
I have experienced problems with Hibernate concerning this question. For example, Hibernate 3.5.x will complain about the Zips table
CREATE TABLE Zips
(
country_code CHAR(2),
code VARCHAR(10),
PRIMARY KEY (country_code, code),
FOREIGN KEY (country_code) REFERENCES Countries (iso_code)
)
with:
org.hibernate.MappingException: Repeated column in mapping for entity: com.kawoolutions.bbstats.model.Zip column: country_code (should be mapped with insert="false" update="false")
org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:676)
org.hibernate.mapping.PersistentClass.checkPropertyColumnDuplication(PersistentClass.java:698)
...
As you can see the country_code column is both PK and FK. Here are its classes:
Entity class:
#Entity
#Table(name = "Zips")
public class Zip implements Serializable
{
#EmbeddedId
private ZipId id;
#ManyToOne
#JoinColumn(name = "country_code", referencedColumnName = "iso_code")
private Country country = null;
...
}
Composite PK class:
#Embeddable
public class ZipId implements Serializable
{
#Column(name = "country_code", insertable = false, updatable = false)
private String countryCode;
#Column(name = "code")
private String code;
...
}
When putting the insertable = false, updatable = false into the entity class association's #JoinColumn all exceptions disappear and everything work fine. However, I don't see why the above code should not be working. It might be Hibernate having problems with this. Is the described a Hibernate bug, as it doesn't seem to evaluate #Column "insertable = false, updatable = false"?
In essence, what's the standard JPA way, the best practice, or preference where to put "insertable = false, updatable = false"?
Let me answer step by step.
1. When do you need ` insertable = false, updatable = false`?
Let's look at the below mapping,
public class Zip {
#ManyToOne
#JoinColumn(name = "country_code", referencedColumnName = "iso_code")
private Country country = null
#Column(name = "country_code")
private String countryCode;
}
Here we are referring to the same column in the table using two different properties. In the below code,
Zip z = new Zip();
z.setCountry(getCountry("US"));
z.setCountryCode("IN");
saveZip(z);
What will Hibernate do here??
To prevent these kind of inconsistency, Hibernate is asking you to specify the update point of relationships. Which means you can refer to the same column in the table n number of times but only one of them can be used to update and all others will be read only.
2. Why is Hibernate complaining about your mapping?
In your Zip class you are referring to the Embedded id class ZipId that again contains the country code. As in the above scenario now you have a possibility of updating the country_code column from two places. Hence the error given by Hibernate is proper.
3. How to fix it in your case?
No. Ideally you want your ZipId class to generate the id, so you should not add insertable = false, updatable = false to the countryCode inside the ZipId. So the fix is as below modify the country mapping in your Zip class as below,
#ManyToOne
#JoinColumn(name = "country_code", referencedColumnName = "iso_code",
insertable = false, updatable = false)
private Country country;
Hope this helps your understanding.
You can also solve this problem by using #PrimaryKeyJoinColumn annotation . The PrimaryKeyJoinColumn annotation specifies a primary key column that is used as a foreign key to join to another table.
The PrimaryKeyJoinColumn annotation is used to join the primary table of an entity subclass in the JOINED mapping strategy to the primary table of its superclass; it is used within a SecondaryTable annotation to join a secondary table to a primary table; and it may be used in a OneToOne mapping in which the primary key of the referencing entity is used as a foreign key to the referenced entity.
If no PrimaryKeyJoinColumn annotation is specified for a subclass in the JOINED mapping strategy, the foreign key columns are assumed to have the same names as the primary key columns of the primary table of the superclass.