Daily Archives: October 1, 2017

Hibernate getResultList() returns same row multiple time

Posted on by

Problem
When using getResultList() to retrieve the Rows of the DB table there may be times where you would end up getting the same rows multiple times.

Why this Happens
Let’s have a table tblGroup the one below

ParentGrp GrpName
Finance Accounts
Finance Sales
  1. You have 2 records in database.Both the records has Finance as value in parentGrp column
  2. Now when you run a select query to select parentGrp = ‘Finance’ you will get 2 records
  3. Lets query them WHERE parentGrp = ‘Finance’
  4. SQL Query returns 2 rows
  5. Hibernate loads first one, and puts into session, with parentGrp as a key.Now this will happen if you have specified it as @ID in entity class or you havent specified it while joining two tables in entity class.The object is placed into the result list.
  6. Hibernate loads second one, notices that an object with the same @Id is already in the session, and just places the reference into the result List. Row data are ignored.
  7. Now we have two copies of the same record

Solution:
We can solve this by introducing a primary key column something like tblGroup_pk_id.Now this helps to uniquely identify the records in the table so it won’t get overridden when the next rows retrieved.

Now the GrpId should be entitled with @ID annotation in the entity class.

GrpId ParentGrp GrpName
101 Finance Accounts
102 Finance Sales

Difference between createQuery vs createSQLQuery vs createCriteria

Posted on by
createQuery() createSQLQuery() createCriteria()
Creates Query Object Creates Query Object Creates Criteria Object
Uses HQL Syntax Uses DB Specific Syntax Uses Entity Class
The Columns of the rows retrieved would be name of the POJO Model Class The Columns of the rows retrieved would be name of Native DB fields Create sql query using Criteria object for setting the query parameters
CRUD operation could be done CRUD operation could be done Only Read Operation is allowed
Supports Interoperability between different DB’s Does not support Interoperability since the query format should be changed when the DB is changed Supports Interoperability between different DB’s
Does not work without Model Class Bean with columns of Table alone is Enough.No need for Entity class generation Does not work without Model Class
No need for mapping between Entity class object and Table Columns The Bean Objects should be mapped with table Columns No need for mapping

createQuery – session.createQuery()

------------------------------------------------------
**DB_TBL_Col(tblEmployee)**| **POJO(Employee)**
EMP_ID                     | employeeID
------------------------------------------------------

Query query = session.createQuery("from Employee E where E.employeeID = 'A%'");
List<Person> persons = query.list();

dependencymanagement vs dependencies tag in maven

Posted on by

parent-pom.xml

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8</version>
    </dependency>
 </dependencies>
</dependencyManagement>

child-pom.xml

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </dependency>
 </dependencies>

Two Main Differeneces

  1. Dependency Management allows to consolidate and centralize the management of dependency versions without adding dependencies which are inherited by all children. This is especially useful when you have a set of projects (i.e. more than one) that inherits a common parent.Another extremely important use case of dependencyManagement is the control of versions of artifacts used in transitive dependencies.You still need to define them in the child POM to show that you are using them. They are not actually included in the child projects just because they are in in the parent POM. Enclosing dependencies in centralizes management of the version, scope, and exclusions for each dependency, if and when you decide to use it.
  2. Artifacts specified in the section <dependencies> will ALWAYS be included as a dependency of the child module(s).Artifacts specified in the section will only be included in the child module if they were also specified in the section of the child module itself. Why is it good you ask? because you specify the version and/or scope in the parent, and you can leave them out when specifying the dependencies in the child POM. This can help you use unified versions for dependencies for child modules, without specifying the version in each child module.

To sum up the above points in simple words in the parent-pom.xml if you are adding things inside tag then it would be available to the child-pom.xml. If you are adding the same thing within tag then you should manually add them to the child-pom.xml.In the child-pom.xml if the version is not specified it will take the parent-pom.xml version of the dependency as default else you can override them by specifying one in child-pom.xml

References Read It