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).
Related
Several years I develop at work in C#, MVC, Entity Framework, database first. Now I want to try Java and choose Play Framework and IDEA as IDE.
Now I search such ORM system as:
easy integrating in Play Framework;
have class generation from database (reverse engineering) as main tool;
have easy language like LINQ in C# (ex: from x in context.MY_TABLE select x)
I strongly advice using jOOQ:
Support to generate model classes from console by only one command: java -classpath jooq-3.1.0.jar;jooq-meta-3.1.0.jar;jooq-codegen-3.1.0.jar;postgresql-9.2-1003.jdbc4.jar;. org.jooq.util.GenerationTool /jooq_config.xml
Full control of your SQL queries.
Easy SQL debugging. Very easy: see here.
Flexible and powerfull API. Full documentation.
Typefase.
Ideal choose for SQL indepth programming.
Supports Java and Scala.
Out-of-box support for advanced SQL types without problems.
Build-in exporting to xml, html, excel
Build-in support to batch inserting.
Good support.
Opensource
Many database engines supported.
Personal feelings
I always loved SQL and I really had chance to work with many ORM with many technologies (.NET: NHibernate, Entity Framework, Linq. Java: Hibernate, JPA. Scala: Anorm SQL) and there were no good solution for me. I used model first and database first. Everytime I used raw SQL and store procedures in most critical points of applications. ORM generate a lot of rubbish which is very difficult to profile and optimize.
When I found jOOQ I was very skeptical. After about 6-8 months working with it I knew that was it. This tool allow you to write every query similar to raw SQL and it's very productive tool. Next thing is that this tool is really fast growing.
Play has build-in ORM - it's Ebean, all you need to use it just uncomment several lines in application.conf (and optionally choose database engine other then build-in H2 ie. MySQL like described in this question)
Next create models package in app folder and start to add your models.
More details in official docs.
Unfortunately it doesn't support reverse engineering...
I'm not aware if IDEA supports DB -> JPA entities reverse-engineering, but Eclipse Dali does this fine - I have used this approach on several projects and were happy with it.
http://www.eclipse.org/webtools/dali/
Play2 works ok with full JPA if wished. Ebean uses only JPA annotations. I like EBean since even if I'm not completely convinced about JPA's criteria API (I have went it thru on JPA 2.0, so don't know how much easier it has come on JPA 2.1) & usefulness of EntityMananager (all hassle with connected / disconnedted entities) I'm big fan of JPA annotations.
For anyone interested in JPA I recommend this book
http://www.amazon.com/Pro-JPA-2-Mike-Keith/dp/1430249269/
BTW: JPA's named queries / JPQL might be ok for sql like simple query needs. Ebean doesn't support JPQL, so if one wants to use it then full JPA implementation like Hibernate or EclipseLink is needed.
Jooq doesn't support nested objects. The idea is good, but not very useful.
I am currently working on an application that uses hibernate as its ORM; however, there is currently no database set up on my machine and I was wanting to start running some tests without one. I figure since hibernate is object/code based that there must be a way to simulate the DB functionality.
If there isn't a way to do it through hibernate, how can this be achieved in the general case (simulation of database)? Obviously, it wont need to handle large amounts of data, just testing functionality.
Just use an embedded DB like Derby
Maybe you could also try to use an ODBC-JDBC bridge and connect to an Excel or Access file, on Windows.
Hibernate is an object-relational mapping tool (ORM). You can't use it without objects and a relational database. Excluding either one makes no sense.
There are plenty of open source, free relational databases to choose from:
MySQL
PostgreSQL
Hypersonic
Derby
MariaDB
SQLite
You're only limited by your ability to download and install one.
Other options are using in-memory database like H2 / hsqldb
I assume you have hidden all the ORM calls behind a clean interface.
If you did, you could simply write another implementation of that interface backed by a Map that caches your objects.
You could then utilize this in your test environment.
But I have to agree with #duffymo, you should just go through the 'first pain' and set up a proper working enviroment.
I'm using H2. One of its major advantages is the use of dialects that simulate the behaviour of the more common DBs. For example - I'm using PostgreSQL and I define the dialect for Hibernate to be PostgreSQL. I'm using it for my integration tests - in each test I create the data that fits my scenario for this test, which is then erased pretty easily. No need to rollback transactions or anything.
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.
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
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.