I'm a little curious, is there a way to modify the hibernate's core so i can customize the generated SQL query. For example, to add functionality in the generated query to use connect by prior (oracle) or any other clause that I want to customize.
At first, such questions always ring some warning bells in me. You have been warned...
AFAIK, hibernate uses so called dialects for specific optimizations. Maybe you could extend one of the existing Oracle dialects or supply your own.
You can create your custom dialect by subclassing the Oracle dialect. That should be the easier approach, in my opinion. I really don't think you want to mess with the Hibernate Core.
DBMS-specific features such as CONNECT BY are usually used in Hibernate applications by issuing native SQL queries. Their results can be mapped to entities so that you can use them almost the same way as regular HQL queries.
Attempts to make Hibernate generate them would be an overkill.
See also:
Chapter 18. Native SQL
Related
I have a Oracle procedure with some 2000 lines with lots of inserts , updates , joins , selects , lot of "insert into select from with multiple and complex joins" I wanted to convert it into java batch. I have multiple options with me to get this done.
Plain JDBC
Spring JDBC template
Hibernate
Spring JPA
I am able to convert the procedure to JAVA using simple plain JDBC and it is working perfectly fine. I optimized the code and it is looking okay. But I would like to consider other alternatives maybe like using Hibernate or JDBC template. Just need suggestions , comments on re-writing it on hibernate. Do you suggest to let it be in plain JDBC or pick any ORM framework ?
Advantages or Disadvantages of picking Hibernate or JDBCtemplate?
Is Hibernate good for complex joins and "insert into select from"??
There is no yes/no answers for these questions. Would like to suggest this link for your analysis:
Spring-JDBC-JPA vs Hibernate
This is about analyzing whether the relational model can be represented in an OO model if you are using an ORM like Hibernate without inducing complexity. If the relational model is complex would like to suggest to use Spring JDBC with native SQL. Spring JDBC handles the boiler-plate issues like opening/closing DB connections,exception handling etc., which needs to be handled by you in the plain old JDBC world.
If you need control on the SQL, since you have mentioned complex joins would be better off writing native SQL. If you are really sure the relational model is properly translated to a robust OO model and you are confident with the SQLs generated by hibernate are optimized based on your foreign-key mappings, then go for hibernate. Of course, there are many convenient features in Hibernate which would not be available in other ORMs. Again, it's about where you want to shift the control, to the developer or the framework. These are my humble suggestions.
Please correct if I have missed out anything.
I haven't worked on JPA so may be other developer experts can comment on that.
I want to make an application which is developed by another developer up and running. When I set up the environment I got sql exception said bad sql grammer. I browsed through internet to get a solution for that. I found that the syntax is oracle native method. But I do not understand how it was working well in earlier days with postgresql.
SELECT * FROM hrms.teammember b, hrms.designationmaster e WHERE b.designationid = e.designation_id(+);
Thanks in advance for your help.
Finally I figured it out. The enterprisedb version advanced server with oracle compatibility software support these native oracle queries.
If you are migrating from one dialect to another, you have only two choices:
Modify the SQL
Use an abstraction framework that can handle the modification on the fly
Since you do not want to use Hibernate, you are left with finding another database abstraction framework. You might do your own search for "java database abstraction layer" and examine the results to see if one will work for you.
If you want to use Hibernate then you must migrate your application from direct JDBC use to Hibernate.
If you have a DB layer specific to postgresql you have no choice but to migrate it, either to Oracle (might be simpler in the short term but won't help you must change the DB again) or to an ORM like Hibernate (may be a bit more complex but you gain compatibility with most DB vendors).
I'm new in persistence and I'm reading the book "Pro JPA 2". I read that the problems of Java and JDBC pack is that
SQL is not portable
Tight coupling between Java code and SQL
The irony of JDBC is that, although the programming interfaces are
portable, the SQL language is not. Despite the many attempts to
standardize it, it is still rare to write SQL of any complexity that
will run unchanged on two major database platforms. Even where the SQL
dialects are similar, each database performs differently depending on
the structure of the query, necessitating vendor-specific tuning in
most cases.
My questions are:
IS the problem linked with SQL portability is still so critical?
As I understand, Hibernate, TopLink and other frameworks also have to create SQL queries from their metadata (annotations). How they arrange the problem linked with SQL portability?
Java & JDBC tight-coupling means that developer have to write SQL queries. Do I understand it correctly?
Thank in advance for your responses )
Yes the problem is with tight coupling between SQL and code and is very critical to project because if we need to migrate from one database to other without ORM, we need to change all the queries in the application.
Hibernate, TopLink and Other ORM Solutions converts your java code into SQL Queries and fires them to the database, but they are more standard and well tested so instead of directly working on Queries we can rely on ORM tools which will convert our code into queries and abstracts us from the complexity. So it is a good idea to use ORM tools instead of directly writing queries.
Yes, Java & JDBC tight-coupling means that developer have to write SQL queries directly which are not portable, and at time if the database layer changes you need to change all the queries. Instead if you use ORM solutions you can migrate to any database supported by ORM directly, by just changing some XML or configuration files.
SQL portability will be an issue if you ever need to switch to different database.
It is easy to think that you will never switch but that can be costly. I've been on projects that assumed the database would always be vendor x but later vendor y database was needed also. Lots of painful, tedious, rework was required to make application work with both databases.
I recommend that you always use standard SQL and/or use an ORM tool that writes only standard SQL.
My ORM, sormula, always creates standard SQL. If you've developed an application with sormula, all that is required to switch databases is to change the jdbc jar.
We are using Eclipselink for ORM, but we have a need for some more lightweight database interactions that are more equivalent to JDBC. My question is whether Eclipselink supports such an idiom and whether there are any advantages of it to straight JDBC. I can see one advantage being consistency and being able to use the existing connection handling. Others?
Specifically, what I'm looking for is something equivalent to Hibernate's Native SQL Query.
If you are using both JPQL and SQL queries in your application then JPA 2 native queries are probably the right approach. Here are some examples :
http://www.oracle.com/technology/pub/articles/vasiliev-jpql.html
If your app only uses SQL queries and updates, then ORM is just an overhead. You can get declarative transactions also differently, for example via Spring's JDBC support.
EclipseLink implements JPA - you can run SQL queries via an EntityManager. If you start running SQL queries not related to the model of your application you'll have no advantages over JDBC - on the contrary you'll be using a much heavier infrastructure. If you tie the SQL to the model however you'll have the advantage of making additional optimizations to queries utilizing the full db potential. I'm not sure if that's what you want to do however...
Does anyone have any experience with creating database agnostic apps in Java, particularly with Hibernate, and simultaneously targeting Oracle and Postgres databases?
In particular I am looking at Oracle Spatial and PostGIS.
We want to create a Java based SOA which can be used with both Oracle Spatial and PostGIS back ends.
I've used Hibernate with both these databases but never with the intention of targeting both.
I can create scenarios where the same code can generate different results depending on which database is used.
It maybe that hibernate can handle this but it would be nice to hear if there are any known problems.
Ken
along with hibernate i can recommend Hibernate Spatial , an extension which supports Mysql, Oracle and Postgre, with their respective GIS extensions.
some pitfalls i encountered:
be aware, the configuration of the dialects was not trivial to do correctly. make sure the dialects are not reconfigured for every statement, as it happened to me.
depending on the features from hibernatespatial you use you might get locked in on a specific version number of hibernate
you can use the criteria api ONLY, hql is not directly supported.
my code using hibernatespatial looks like this:
if (query.getMaxDistance() != null && query.getCenter() != null) {
basicCriteria.add(SpatialRestrictions.within("coordinate", GeoidCircleFactory.circle(query.getCenter(), query.getMaxDistance())));
}
you will suffer from some of the quite dire constraints postgis and others are under.
i would recommend to relax some of your application needs to better fit the possibilities of your DB. for example, queries in "angle space" are much easier to do than in "euclidean space".
the code contained in GeoidCircleFactory looks quite scary... :)
In addition to using Hibernates dialects you will want a database creation management tool like Liquibase which will allow the creation code to be abstracted away from the specific syntax of the different databases.
Hibernate handles targetting different databases using its Dialect abstraction. You don't need to make any changes to your application itself only the hibernate configuration for each database.
You can either specify in your configuration the dialect to use with your database or allow Hibernate to use the JDBC driver settings to determine the appropriate dialect.
Following the comment received, have you looked at Hibernate Spacial? It is an extension to Hibernate to support geographic data by providing the necessary Hibernate types and dialects.