Hibernate translation capabilities - java

Our project must be able to run both in Oracle and SQL Server. The problem is we have a number of HQL + native queries with non-standard operators (i.e. bitand and || ) and functions ( i.e. SUBSTR ) that work fine in Oracle but not in SQL Server.
I wonder if Hibernate is capable of translating them dynamically. I suppose that with HQL maybe it does, because it creates an AST but I doubt the same applies with native queries.
Additional question: what's the best approach of dealing with these troublesome queries ? Conditionals, subclassing, others ... the goal is not to modify the code a lot.
Thanx in advance

Use custom Dialects for HQL. Instead of using ||, create your own function called concat. Then, in the SQL Server dialect add this to the constructor:
registerFunction("concat", new VarArgsSQLFunction(Hibernate.STRING, "", "+", ""));
You don't have to change the Oracle dialect because Oracle already has a concat function so it just passes through, but for other functions, you may need to register new functions in both.
For SQL queries, since you're building them dynamically anyway, you could use base class methods, for example super.addBitAndClause(leftSide, rightSide).
You can even get to the dialect dynamically, although Hibernate didn't make it easy by putting on the interface:
Dialect d = ((SessionFactoryImpl)sessionFactory).getDialect()

I suggest moving the HQL queries from the code to an external .hbm file and to use named queries before switching the Database. The HQL queries shouldn't be a problem as you already said. Native queries are a problem and you have to find the equivalent for the other DBMS. But by putting the queries into the external file you can then configure the sessionfactory to use the database specific .hbm file and do not need to change the code which depends only on the named query which can be a native query or a HQL
To get a named Query you can do the foloowing:
Query query = session.getNamedQuery("YourNamedHQLorSQLQuery");

Related

JPA Hibernate query vs Native query

I use Spring Data JPA (hibernate) generated queries for fetching data from my Sqlserver. Now i am getting performance related issues in my system.
Load findByLoadId(Integer loadId);
This is the query i am using to get data. This query returns 25 cell data but i only use 5 data from that.
can i use direct native query like
select id,date,createdBy,createdOn,loadName from Load where
loadId=:loadId
but if native query is suggestable then I am having question like Does ORM frameWork reduce performence by getting unneeded data from Database?
By "data cell" I assume that you are referring to database table columns, and not to records. The answer to your question is that yes, ORM frameworks might tend to just do a SELECT * under the hood, which can result in unwanted information being sent across the network to your application. If the JPA repository interface is behaving this way, you may switch to either an explicit JPA query (e.g. using the #Query annotation), or even a native query. Then, just select the columns you want. The issue here is that ORM frameworks map object templates (e.g. classes) to entire database tables. So, the concept of entity implicitly includes every database column. If you go with the option of selecting only certain columns, you may need to do some juggling on the Java side. Note that if the use a JPA query, your code would still, in theory, be database independent.

Is there any disadvantages with using createNativeQuery() method of JPA

I have a big query with so many joins and I have tried for JPQL implementation (using createQuery() method)of the query but I am getting so many syntax problems with usage of entities instead of table names. So I have chosen native query implementation as it is executing my query properly on my Oracle DB.
Is native query is DB specific? and If we change the DB from Oracle to other DB like MySql or SQLServer, will it work?. Please help me on this, thanks in advance.
Take a look at this page that shows some differences among mysql, Oracle, and mssql:
http://www.bristle.com/Tips/SQL.htm#differences_in_sql_syntax
You can see that there are differences in the way certain kinds of joins are specified.
So yes, you may have problems with complex queries if you choose to use the native query implementation and the switch databases.

Hibernate produce different SQL for every query

I've just tested my application under the profiler and found out that sql strings use about 30% of my memory! This is bizarre.
There are a lot of strings like this stored in app memory. This is SQL queries generated by hibernate, note the different numbers and trailing underscores:
select avatardata0_.Id as Id4305_0_,...... where avatardata0_.Id=? for update
select avatardata0_.Id as Id4347_0_,...... where avatardata0_.Id=? for update
Here is the part I can't understand. Why does hibernate have to generate different sql strings with different identifiers like "Id4305_0_" for each query? Why can't it use one query string for all identical queries? Is this some kind of trick to bypass query caching?
I would greatly appreciate if someone would describe me why it happening and how to avoid such resource wasting.
UPDATE
Ok. I found it. I was wrong assuming memory leak, It was my fault. Hibernate is working as intended.
My app created 121(!) SessionFactories in 10 threads, they produced about 2300 instances of SingleTableEntityPersisters. And each SingleTableEntityPersister generates about 15 SQL queries with different identifiers. Hibernate was forced to generate about 345.000 different SQL queries. Everything is fine, nothing weird :)
There is a logic behind the query string that hibernate generates. Its primary aim is to get unique aliases for tables and columns names.
From your query,
select avatardata0_.Id as Id4305_0_,...... where avatardata0_.Id=?
avatardata0_ ==> avatardata is the alias of the table and 0_ is appended to indicate it is the first table in the query. So if it were the second table(or Entity) in the query it should have been shown as avatardata1_. It uses the same logic for the column aliases.
So, this way all the possible conflicts are avoided.
You are seeing theses queries because you have turns on the show_sql flag the configuration. This is intended for the debugging of queries. Once you application started working you are supposed turn it off.
Read more on the API docs here.
I am not much aware of the memory consumption part, but you repeat your tests with the above flag turned off and see if there is any improvement.
Assuming you are using sql server, you might want to check the parameter type declaration for '?', making sure the declaration results in the same, fixed length declaration every time.
Dynamic length parameters would result in separate execution plans for each query. This could possibly comsume a lot of resources. What we see as the same procedure, get's interpreted by sql server as a different query, rendering a separate execution plan.
Thus,
exec myprocedure #p1 varchar(3)='foo'
and
exec myprocedure #p1 varchar(6)='foobar'
would result in different plans. Simply by the fact that the declarations of #p1, differ in size.
There is a lot to know about this behaviour. If the above applies to you, I would recommend you read up on 'parameter sniffing'.
No... you can generate you common query inside the hibernate. The logic behind is to mapping with table and fetch the record from there. It is used common query for all the database. Please create a common query like that :
Example :
select t.Id as Id4305_0_,...... from t where t.Id=?

Design Problem - Generating SQL Queries for business calculations

We have an application where the user is allowed to enter expressions for performing calculations on the fields of a database table. The calculations allows various types of functions (math, logic, string, date etc). For e.g MAX(col1, col2, col3).
Note that these expressions can get complex by having nested functions. For e.g.
IF(LENGTH(StringColumn)=0, MAX(col1, col2, 32), MIN(col1, col2, col3)) > LENGTH(col2)
One way we have implemented this is having a java cc parser to parse the user entered expressions and then generating a tree type of data structure. The tree is then parsed in java and sql queries are generated for each of the functions used in the expressions. Finally after the queries are generated for each of the user entered expression, java executes this query using simple database call.
A major problem with this framework is that the database issues are to be handled in java. By database issues I mean some database limitation or any performance optimization. One database limitation with Microsoft SQL Server is that only 10 nested CASE WHEN statements are allowed. This means that while parsing the java code needs to estimate how many CASE WHEN's would the query string have before it is translated.
Similarly if there are any sql performance optimizations to be done, handling them in java simply not logical.
Does anyone know about any better design approaches for this problem?
Rather than reimplement a very SQL-like language that gets translated to SQL, have your users query the database with SQL.
I would look into Hibernate and it's HQL query language.
In response to the poster above, I think it would be a bad idea to let your users query the database with SQL directly, as you'd be opening yourself up to SQL injection attacks.
Some time ago i wrote a java applet with dynamic filter routines and there i translate the sql statements to javascript statements and execute them with javascripts exec function
You could have a look at JPA 2.0 Criteria API or Hibernate Criteria API
JPA 2.0 provides the so called Criteria API (http://stackoverflow.com/questions/2602757/creating-queries-using-criteria-api-jpa-2-0)
Hibernate has its own Criteria API (even before JPA 2.0) - but it is different from JPA 2.0 Criteria API. (http://www.ibm.com/developerworks/java/library/j-typesafejpa/)
The aim of both Criteria APIs is to provide a way to create sql queries at runtime in a more pleasant way then concatenating strings. (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querycriteria.html)
(JPA 2.0 Critiera API has a extra feature, it provides some kind of code generation, that makes it possible to write queries in a compile time save way. (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querycriteria.html))
Another approach which I could think was to look for language recognizers supported by database (which is Oracle in my case). Similar to what we currently use in java (i.e. javacc) if a similar framework is supported by the database then the intermediate string could be parsed and translated into a sql query.
The intermediate string I refer here is similar to the user entered string but may be exactly the same (e.g. column names could be transformed to actual physical column names).
Any thoughts (pros and cons) about this approach? Also any suggestions on language recognizers in Oracle would be highly appreciated.
Thank you.

Is HibernateCallback best for executing SQL/procedures?

I'm working on a web based application that belongs to an automobil manufacturer, developed in Spring-Hibernate with MS SQL Server 2005 database.
There are three kind of use cases:
1) Through this application, end users can request for creating a Car, Bus, Truck etc through web based interfaces. When a user logs in, a HTML form gets displayed for capturing technical specification of vehicle, for ex, if someone wanted to request for Car, he can speify the Engine Make/Model, Tire, Chassis details etc and submit the form. I'm using Hibernate here for persistence, i.e. I've a Car Entity that gets saved in DB for each such request.
2) This part of the application deals with generation of reports. These reports mainly dela with number of requests received in a day and the summary. Some of the reports calculate Turnaround time for individual Create vehicle requests.
I'm using plain JDBC calls with Preparedstatement (if report can be generated with SQLs), Callablestatement (if report is complex enough and needs a DB procedure/Function to fetch all details) and HibernateCallback to execute the SQLs/Procedures and display information on screen.
3) Search: This part of application allows ensd users to search for various requests data, i.e. how many vehicle have been requested in a Year etc. I'm using DB procedure with CallableStatement..Once again executing these procedures within HibernateCallback, populating and returning search result on GUI in a POJO.
I'm using native SQL in (2) and (3) above, because for the reporting/search purpose the report data structure to display on screen is not matching with any of my Entity. For ex: Car entity has got more than 100 attributes in itself, but for reporting purpose I don't need more than 10 of them.. so i just though loading all 100 attributes does not make any sense, so why not use plain SQL and retrieve just the data needed for displaying on screen.
Similarly for Search, I had to write procedures/Functions because search algorithm is not straight forward and Hibernate has no way to write a stored procedure kind of thing.
This is working fine for proto type, however I would like to know
a. If my approach for using native SQLs and DB procedures are fine for case 2 and 3 based on my judgement.
b. Also whether executing SQLs in HibernateCallback is correct approach?
Need expert's help.
I would like to know (...) if my approach for using native SQLs and DB procedures are fine for case 2 and 3 based on my judgment
Nothing forces your to use a stored procedure for case 2, you could use HQL and projections as already pointed out:
select f.id, f.firstName from Foo f where ...
Which would return an Object[] or a List<Object[]> depending on the where condition.
And if you want type safe results, you could use a SELECT NEW expression (assuming you're providing the appropriate constructor):
select new Foo(f.id, f.firstName) from Foo f
And you can even return non entities
select new com.acme.LigthFoo(f.id, f.firstName) from Foo f
For case 3, the situation seems different. Just in case, note that the Criteria API is more appropriate than HQL to build dynamic queries. But it looks like this won't help here.
I would like to know (...) whether executing SQLs in HibernateCallback is correct approach?
First of all, there are several restrictions when using stored procedures and I prefer to avoid them when possible. Secondly, if you want to return entities, it isn't the only way and simplest solution as we saw. So for case 2, I would consider using HQL.
For case 3, since you aren't returning entities at all, I would consider not using Hibernate API but the JDBC support from Spring which offers IMHO a cleaner API than Session#connection() and the HibernateCallback.
More interesting readings:
References
Hibernate Core reference guide
14.6. The select clause (about the select new)
16.1.5. Returning non-managed entities (about ResultTransformer)
16.2.2. Using stored procedures for querying
Resources
Hibernate 3.2: Transformers for HQL and SQL
Related questions
hibernate SQLquery extract variable
hibernate query language or using criteria
You should strive to use as much HQL as possible, unless you have a good argument (like performance, but do a benchmark first). If the use of native queries becomes to excessive, you should consider whether Hibernate has been a good choice.
Note a few things:
you can have native queries and stored procedures that result in Hibernate entities. You just have to map the query / storproc call to a class and call it by session.createSQLQuery(queryName)
If you really need to construct native queries at runtime, the newest version of hibernate have a doWork(..) method, by which you can do JDBC work.
You say
For ex: Car entity has got more than 100 attributes in itself, but for reporting purpose I don't need more than 10 of them.. so i just though loading all 100 attributes does not make any sense
but HQL in hibernate allows you to do a projection (select only a subset of the columns back). You don't have to pull the entire entity if you don't want to.
Then you get all the benefits of HQL (typing of results, HQL join syntax) but you can pretty much write SQLish code.
See here for the HQL docs and here for the select syntax. If you're used to SQL it's pretty easy.
So to answer you directly
a - No, I think you should be using HQL
b - Becomes irrelevant if you go with my suggestion for a.

Categories