Hi I have one table VariantValidityBE
It has a relationship column like this
#OneToMany(mappedBy = "variantValidityBE", fetch = FetchType.LAZY)
private List<VariantValidityValueBE> variantValidityBEList;
And in another table
#ManyToOne
#JoinColumn(name = "CATEGORY_ID", referencedColumnName = "ID")
private VariantValidityBE variantValidityBE;
And my method is like this
List<VariantValidityBE> resultList = getResultList(VariantValidityBE.FIND_ALL);
for (VariantValidityBE variantValidityBE : resultList) {
List<VariantValidityValueBE> options = variantValidityBE.getVariantValidityBEList();
}
the value of option is coming old value, newly inserted child record is not coming
Values are inserted into DB correctly.
But if I restart the application its giving the updated records.
The same type of relations I used so many times, never get such type problem.
Since JPA entities are treated as regular java objects, you are required to keep both sides of bidirectional relationships in synch with each other when making changes. JPA will not perform magic to mirror changes made to one side of a bidirectional relationship to the other for you. So when you add a new VariantValidityValueBE instance and set its variantValidityBE, you must also add the VariantValidityValueBE to the variantValidityBEList. Otherwise, the variantValidityBEList will remain unchanged and stale until it is refreshed from the database.
Related
I have one entity class, which consists of multiple foreign key constraints, which are handled by ManyToMany etc.
public class MyExampleClazz {
.......
#ManyToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
#JoinTable(name = "secondClazzEntities", joinColumns = #JoinColumn(name = "id"),
inverseJoinColumns = #JoinColumn(name = "id"))
List<MySecondClazz> secondClazz;
.....
}
For some cases, I would like to change the fetching strategy from e.g. from EAGER to LAZY and vice versa, because for some read operations, I don't need EAGER fetching (imagine a RESTful service , which offers only some small portion of data and not everything) but in most cases I need EAGER instead.
One option could be introduce an entity (for same table) but different annotation, but it would duplicate code and effort in regards of maintenance.
Are there other ways present, to achive the same result by doing less?
There're two layers where you can control data fetching in JPA:
At the level of entity class via fetch type and fetch mode
At the query level via the "join fetch" clause or using #EntityGraph
I suggest you use FetchType.LAZY, by default for almost all associations. And fetch them only when you need them via #EntityGraph.
I have a problem with orphanRemoval. When I Delete Member and if there is no others Members referenced relation given, this relation should be deleted. But this is not the case. There is the moyen to do this with JPA configs, or I should write logic in Service ?
public class Member {
#ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
public RelationEntity getBornRelation() {
return bornRelation;
}
}
public class Relation {
#OneToMany(fetch = FetchType.EAGER, orphanRemoval = true, cascade = CascadeType.ALL)
#JoinColumn(name = "bornrelation")
public List<MemberEntity> getChildren() {
return children;
}
}
First of all, you've defined two separate associations between Member and Relation. I suspect that wasn't intentional. If you want to keep the association bidirectional, you need to make the 'one' side the owning side of the association by adding mappedBy="bornRelation" to the #OneToMany. Otherwise, changes to Member.bornRelation will not be reflected in Relation.children and vice versa.
Secondly, do not use CascadeType.ALL with #ManyToOne. CascadeType.ALL implies CascadeType.REMOVE and an attempt to remove the 'one' side of the association will fail as long as the 'many' side still contains other child entities that refer to the parent entity. JPA will not check if the deletion is possible. It will simply issue a DELETE to the database, resulting in constraint violations.
(you can keep using CascadeType.ALL with #OneToMany, but remember that you still need to make sure Member.bornRelation is set properly when adding new elements to Relation.children. JPA will not take care of that for you)
I believe the above already answers your question. What you want cannot be done by JPA configuration only, you need additional logic to check whether the Relation to delete is the last child of its parent entity. This, by the way, has nothing to do with orphan removal. Orphan removal is about removing child entities (and not parent entities).
I have a many-to-many relationship where the link table has an additional property. Hence the link table is represented by an entity class too and called Composition. The primary key of Composition is an #Embeddable linking to the according entities, eg. 2 #ManyToOne references.
It can happen that a user makes an error when selecting either of the 2 references and hence the composite primary key must be updated. However due to how JPA (hibernate) works this will of course always create a new row (insert) instead of an update and the old Composition will still exist. The end result being that a new row was added instead of one being updated.
Option 1:
The old Composition could just be deleted before the new one is inserted but that would require that the according method handling this requires both the old and new version. plus since the updated version is actually a new entity optimistic locking will not work and hence last update will always win.
Option 2:
Native query. The query also increments version column and includes version in WHERE clause. Throw OptimisticLockException if update count is 0 (concurrent modification or deletion)
What is the better choice? What is the "common approach" to this issue?
Why not just change the primary key of Composition to be a UID which is auto-generated? Then the users could change the two references to the entities being joined without having to delete/re-create the Composition entity. Optimistic locking would then be maintained.
EDIT: For example:
#Entity
#Table(name = "COMPOSITION")
public class Composition {
#Id
#Column(name = "ID")
private Long id; // Auto-generate using preferred method
#ManyToOne(fetch = FetchType.LAZY, optional = false)
#JoinColumn( .... as appropriate .... )
private FirstEntity firstEntity;
#ManyToOne(fetch = FetchType.LAZY, optional = false)
#JoinColumn( .... as appropriate .... )
private SecondEntity secondEntity;
....
I have a field declared as a Map<MyEnum, String>, which is audited. When a change is made to one of the elements in the map, envers is generated two edits, an ADD and a DEL, rather that a single MOD, which in turn means a constraint violation when trying to insert into the audit table, since there are two edits for a single field in a single entity in the same revision.
I'm guessing I could probably work around the problem by making revision_type part of the table's key (which would permit one edit of each type per field per entity), but that seems like an ugly hack, besides the fact that I lose track of which happened first, and the fact that it's just wrong.
The field is being persisted properly, by the way... it's just the audit records that fail.
The field's declaration:
#ElementCollection
#CollectionTable(name = "configuration_property", joinColumns = #JoinColumn(name = "configuration_id"))
#MapKeyColumn(name = "property_name")
#Column(name = "property_value", columnDefinition = "longtext")
#MapKeyEnumerated(EnumType.STRING)
private Map<ConfigurationProperty, String> properties = new EnumMap<ConfigurationProperty, String>(ConfigurationProperty.class);
I'm using Hibernate v3.5.6.
I haven't been able to find any bug reports regarding this, so I'm thinking I'm doing something wrong... any ideas?
If you look at AbstractCollectionMapper.mapCollectionChanges, the current implementation only does additions and removals. I think the map is viewed as a collection of tuples: (key, value), so there are never any modifications. The bug is then in the schema generation, which should generate the keys properly. Please file a JIRA bug - https://hibernate.onjira.com, Envers component.
After struggling for days attempting to get back collections that are linked to a table via a foreign key, I just realized that the tables I am linking to are actually LINKING tables to other tables with the actual data (chock one up for normalized tables).
I am still struggling to get collections out of ManyToOne annotated variables with references to foreign keys, but is there a way I can pull the data back from the table that actually contains the information? Has anyone run into an instance of this?
UPDATE: AS per request I will be posting some code instances... This would be my named query in the entity that I will be calling...
#NamedQuery(name="getQuickLaunchWithCollections", query = "SELECT q FROM QuickLaunch q LEFT JOIN FETCH q.quickLaunchDistlistCollection LEFT JOIN FETCH q.quickLaunchPermCollection LEFT JOIN FETCH q.quickLaunchProviderCollection")})
These would be the collections that I am looking to fill...
#OneToMany(mappedBy="quickLaunchId", fetch=FetchType.EAGER)
private List<QuickLaunchPerm> quickLaunchPermCollection;
#OneToMany(mappedBy="quickLaunchId", fetch=FetchType.EAGER)
private List<QuickLaunchProvider> quickLaunchProviderCollection;
#OneToMany(mappedBy="quickLaunchId", fetch=FetchType.EAGER)
private List<QuickLaunchDistlist> quickLaunchDistlistCollection;
As you can see, I have the fetch type set to eager. So technically, I should be getting some data back? But in actuality those are just linking tables the data that I actually want to pull back. I will need to figure out how to get that data back eventually.
This is how I am calling that named query...
listQL = emf.createNamedQuery("getQuickLaunchWithCollections").getResultList();
Alright, it appears as though LEFT JOIN FETCH
is causing my runtime to throw an expception of some kind. It is pretty unclear as to what it is. But I feel as though I am getting no where with that technique. I am going to try something slightly different.
I would suggest simplifying example, to face the problem, since you are going worldwide now.
Specifying mappedBy="quickLaunchId" attribute, you are saying, that QuickLaunchPerm entity has QuickLaunch as its property named "quickLaunchId". Is this true?
If it is not, then you need to define it in QuickLaunchPerm:
#ManyToOne(fetch = FetchType.EAGER)
#JoinColumn(name = "QUICK_LAUNCH_ID")
private QuickLaunch quickLaunchId;
//getters setters