SQL with Hibernate Criteria

Hibernate's Criteria is a very comprehensive API which provides the user alot of flexibility to write dynamic queries. But of course nothing is perfect. I came across a situation where i had to truncate a date field in order to get the correct result set without considering the time portion. While going through the Criteria API I did not find anything which allowed me to do this. And hence in the path for a solution i found out that Criteria allows for plain SQL syntax to be included which i thought was a big plus point because it gives the developer the flexibility without restricting him/her just to the API.

The following code depicts the way you can incorporate plain SQL to your criteria API.

DetachedCriteria testCirteria = DetachedCriteria.forClass(Employee.class);
 SimpleDateFormat dateFormatForSearch = new SimpleDateFormat("dd/MM/yyyy");
 Calendar joinDate = empSearchDTO.getJoinDate();

  if (joinDate != null) {
      /**
 The following uses DateUtils of apache commons to truncate the<br>
 date object.
      **/
      joinDate = DateUtils.truncate(joinDate, Calendar.DATE);
      String dateAsStr = dateFormatForSearch.format(joinDate.getTime());
      testCirteria.add(Restrictions.sqlRestriction("trunc(emp_join_date)=to_date('" + dateAsStr + "','dd/mm/yyyy')"));

   }

As you can see the Criteria API allows to put any valid SQL within the Restrics.sqlRestriction() method. Here i have used the trunc function.

Thats it. If you have any queries or suggestions pls do leave a comment.

Cheers!!!!

Why the saying "If all you have is a hammer then everything looks like a nail" is so true in the IT industry

"If all you have is a hammer then everything looks like a nail" - Now do not ask me who quoted this or from where i found it.. I vaguely remember seeing it on one of my buddies gtalk status some time back. But the reality of this statement struck me a week back.

We had got this new project in our company. Not a major high scale project. But involved some calculations. Was very interesting. Our company has a few frameworks developed around the years which is used as best practice for many projects. When our architect got this project he without even considering the architectural perspective of the project put in an already existing framework to start development.

Note that this was a project that involved just two(three including the login page) pages. But the technologies included in the framework were as follows;

1. EJB 3.0
2. JMS
3. Spring
4. Hibernate
5. Freemarker
6. Jasper
7. Struts 2.0

and a few others which i cannot recall at this moment. And i was thinking to my self from all these what we actually needed to do this project. And this was all bundled up into an EAR which came to a size of a thumping 30MB :S... I was amazed at why such a person with so many years of experience would go for such an inappropriate solutions. Of course looking at it from his perspective im sure the higher management would have given him ridiculously tight dead lines to finish the project which lead him into jumping to an existing framework. And also this project was under a maven build. I mean come on, to build a freaking 3 page module it takes around 2mins because of all the dependent modules existing in the framework which is almost always never ever going to be used within this project. Talk about time waste.

In my opinion my technology stack for this project would have been using a simple ANT build using Spring to wire up and handle transactions with Hibernate and struts to handle the mediation layer and bundle it up as a WAR. Ofcourse some time back i did a solution where all the commonly used JARs were bundled up in a single jar which was deployed only once(Note that we use JBoss A/S as our application servers). This is because if you really look at it, the project it self is only a few MBs of size. But what takes most of the space is the third party libraries we use. This solution lead to lesser deployment time because else it takes alot of time to do a remote deployment to the servers if the file size is large.

The fact lies with why we cant think beyond what already exists. To think the same framework works in all situations is like thinking one antibiotic will cure all viruses. Of course time lines are an essential component. But if you really look at it, using the right tool for the right job will help you finish up the job with time to spare rather than using an existing framework and removing all parts which you do not need which is both time consuming and error prone. 

So my theory is dont have just a hammer, but have a tool kit with various options under your belt which will serve you and your team mates better where by will be better for your company as well.