Please enable JavaScript.

Coggle requires JavaScript to display documents.

Hibernate (PersistenceContext (automatic dirty checking (Definition: For…

- - - - Java uses "ordered collection" to mean a collection such as List, where (unlike HashSet), the collection remembers what order the elements are supposed to be in. So elements can be added to the collection at a particular "place" in the order.
        Java uses "sorted collection" to mean a collection such as SortedSet, where (unlike List), the order that the iterator traverses the collection is in accordance with a specified Comparator or the natural order of the elements.
        So the difference is whether the ordering depends on the values ("sorted"), or is a property that elements have independently of their value ("ordered"). Printing HashSet will have different result for every print.
- - - - Hibernate will not actually load all children when you access the collection. Instead, it will load them when requested for the first time. When iterating over the collection, this causes a query for every entity (there is n of them) + 1 query to get those n parent entities.http://mkorwel.blogspot.com/2012/04/hibernate-n1-select-problem.html
      - What's more if the session is already closed, you will get the LazyInitializationException if association was not fetched before.
  - - - to track arguments as well
- - - - What happens after the persist method is called? The object is in the persistence context now, but not yet saved to the database. The generation of INSERT statements will occur only upon commiting the transaction, flushing or closing the session. Id is also not generated yet.
      - You may call this method on an already persistent instance, and nothing happens. But if you try to persist a detached instance, the implementation is bound to throw an exception
    - - it persists the instance, “first assigning a generated identifier”
      - The call of save on a detached instance creates a new persistent instance and assigns it a new identifier, which results in a duplicate record in a database upon committing or flushing.
  - - - The main intention of the merge method is to update a persistent entity instance with new field values from a detached entity instance.
      - this operation cascades for all relations with cascade=MERGE or cascade=ALL mapping;
      - if the entity is persistent, then this method call does not have effect on it (but the cascading still takes place). If the merging entity has no equivalent in the current Session, one will be fetched from the database.
        The detached object instance will continue to remain detached even after the merge operation.
      - returns new object
    - - it acts upon passed object (its return type is void); the update method transitions the passed object from detached to persistent state;
      - this method throws an exception if you pass it a transient entity.
      - is a true hibernate method, unlike merge which was added later
    - - Similar to update, it also may be used for reattaching instances.
      - The main difference of saveOrUpdate method is that it does not throw exception when applied to a transient instance; instead, it makes this transient instance persistent.
- - - - auto
        
        The Session is sometimes flushed before query execution.
      - commit
        
        The Session is only flushed prior to a transaction commit.
      - manual
        
        The Session can only be manually flushed.
      - always
        
        The Session is always flushed before query execution.
      - never - deprecated, use manual instead
    - - auto - JPA is more strict, and the AUTO flush mode must trigger a flush before any query.
      - commit
- - - - The detach operation removes the entity from the persistent context. When we use CascaseType.DETACH, the child entity will also get removed from the persistent context.
    - - The merge operation copies the state of the given object onto the persistent object with the same identifier. CascadeType.MERGE propagates the merge operation from a parent to a child entity.
    - - The persist operation makes a transient instance persistent. CascadeType PERSIST propagates the persist operation from a parent to a child entity
    - - Refresh operations re-read the value of a given instance from the database. In some cases, we may change an instance after retrieving from the db, but later we don't want dirty entity, (with our changes) to start from beginning.
    - - As the name suggests, the remove operation removes the row corresponding to the entity from the database and also from the persistent context.
  - - - It's useful when we use Hibernate-specific operations like save, update, and saveOrUpdate.
    - - is useful for some very specific scenarios (when the exact entity state needs to be mirrored between two distinct DataSources),
    - - Unintuitively, CascadeType.LOCK re-attaches the entity and its associated child entity with the persistent context again.
      - Person person = buildPerson("devender"); Address address = buildAddress(person); person.setAddresses(Arrays.asList(address)); session.persist(person); session.flush(); assertThat(session.contains(person)).isTrue(); assertThat(session.contains(address)).isTrue(); session.detach(person); assertThat(session.contains(person)).isFalse(); assertThat(session.contains(address)).isFalse(); session.unwrap(Session.class) .buildLockRequest(new LockOptions(LockMode.NONE)) .lock(person); assertThat(session.contains(person)).isTrue(); assertThat(session.contains(address)).isTrue();
- - - - Annotation used on other annotations, like
        @NamedQuery
        which tells the Java compiler that it should generate contatiner annotation for this annotation. It simplifies code a bit.
- - - - use JOIN FETCH to avoid it
      - Use DTO projection if you need that entity to read only. DTO is not an entity,it should be lighter and contain fewer fields. If update is needed, we have to use entity, as only this can be managed by entityManager or Session object.
- - - - When a proxy is loaded, the data is not stored in the proxy object, but in the “target” object (in CGLIB$CALLBACK_0) . The fields in the proxy object will remain null forever (or any value that they have been initialized with), since all methods invoked on the proxy will be delegated to the target object.
        The main area where this Pitfall arises is the equals(..) method. As when we operate directly on fields (not getters and setters) we refer to nulls, so this fails : personObject.equals(personProxy).
      - A proxy will be a subclass of the field type that is required. Hibernate will look at the type of the field and create a dynamic class with that type, adding the necessary functionality. This means that if the field type is not the actual implementation type, but an interface or superclass, the type of the proxy will be different than the type of the actual object: If the field-type is the superclass of the actual implementation, the proxy-type and the implementation-type will be siblings in the type hierarchy, both extending the superclass.
  - - - Although bytecode enhancement can be done at compile-time, runtime or deploy time, the compile-time alternative is preferred for the following reasons:
        
        the enhanced classes can be covered by unit tests
        
        the Java EE application server or the stand-alone container (e.g. Spring) can bootstrap faster because there’s no need to instrument classes at runtime or deploy-time
        
        class loading issues are avoided since the application server doesn’t have to take care of two versions of the same class (the original and the enhanced one).
      - When enabling the dirty tracking option (it can be done by adding maven plugin) , Hibernate will track property changes through the following mechanism: the $$_hibernate_tracker attribute stores every property change, and every setter method will call the $$_hibernate_trackChange method.
      - @Transient private transient DirtyTracker $$_hibernate_tracker; public void $$_hibernate_trackChange(String paramString) { if (this.$$_hibernate_tracker == null) { this.$$_hibernate_tracker = new SimpleFieldTracker(); } this.$$_hibernate_tracker.add(paramString); }
      - public void setTitle(String title) { this.title = title; } ... becomes public void setTitle(String title) { if(!EqualsHelper.areEqual(this.title, title)) { this.$$_hibernate_trackChange("title"); } this.title = title; }
      - The entity snapshot is still saved in the Persistence Context even when using bytecode enhancement.
        For this reason, keeping the Persistence Context in reasonable boundaries holds on no matter the dirty tracking mechanism in use.
- - - - The bidirectional associations should always be updated on both sides, therefore the Parent side should contain the addChild and removeChild combo. These methods ensure we always synchronize both sides of the association, to avoid object or relational data corruption issues.
      - The main differenece is that bidirectional relationship provides navigational access in both directions, so that you can access the other side without explicit queries. Also it allows you to apply cascading options to both directions.
    - - For a unidirectional association, you can navigate the association from one end only. So, for a unidirectional ManyToOne association, it means you can only access the relationship from the child side where the foreign key resides
      - Hibernate looks at the owning side of relationship when persisting it, so if we have Group that has many users, we can set only User.group if we want to add it to a certain group. However, if you want to keep objects in memory consistent, you also need to add User to Group.users. But it would make Hibernate to fetch all elements of Group.users from the database, which may throttle our app.
      - If you have a unidirectional OneToMany association, it means you can only access the relationship from the parent side where the foreign key resides.
  - - - It's the only solution to map a ManyToMany association : you need a join table between the two entities tables to map the association
      - It's also used for OneToMany (usually unidirectional) associations when you don't want to add a foreign key in the table of the many side and thus keep it independent of the one side.
      - It's also cleaner to use JoinTable when an Entity could be the child in several parent/child relationships with different types of parents. Should the table have e.g. 5 nullable foreign key fields? I think not...
- - - - Here we are using JOIN to query all employees that have at least one department associated. If Fetch was absent, then Employee entities would not have their Department sub-entities loaded into persistence context.
        FROM Employee emp JOIN FETCH emp.department dep