We Keep Coding

Join without mapping entities in spring

Am not that good yet with spring. Before now I thought its unprofessional to build an application with spring without using hibernate ORM. Until yesterday when I spent a full day trying to execute a "ManyToOne" mapping. Then I came across some threads where I got to know that u should only use hibernate with spring if only u need ORM in your application. That jdbc template will suffice should you not need ORM. Now my question is do I still need relational mapping to execute JOINS in SPRING using JDBC TEMPLATE(without using hibernate at all)

Spring JdbcTemplate allows you deal with native Java driver to work with databases, writing less code than using it directly. As you have guessed, it is a good option when the performance is more important than build a robust application using the "easy way" that brings you an ORM like Hibernate for example.
Answering your question, if you are talking about the Hibernate annotations like #ManyToOne or similar, the answer is no. Using JdbcTemplate you won't need them. However, you will need to specify in every query what are the required columns of every table and the columns of the related ones that you will want to get.
The following links give you some examples about how to deal with JdbcTemplate and joins:
Example 1
Example 2
More information about JdbcTemplate here

When to use MongoDB Driver/Morphia over Hibernate

I am currently working with MongoDB and Java and I have to decide if I use MongoDB's Driver, Morphia or Hibernate. Can anyone tell me what the advantages and disadvantages of Hibernate, MongoDB's Driver and Morphia are? And in what situation should I use which? A small example would also be nice, but is not really necessary.
Thanks!

Using a native driver :
It is always better if you have time to learn that driver.
Now coming to Mongo-Java-Driver it is quite simple to use. Initially terms like BasicDBObject, BSONObject may sound odd to you. After some time, you will find it comfortable. You can start with this quick tour to Mongo Java Driver.
Using ORM tool :
ORM tools like spring data, Kundera, Morphia use these native drivers internally. These makes it simple and comfortable to the user with some overhead in terms of performance sometimes.
So, it's up to you if you have time to explore go for Mongo-Java-Driver. otherwise, go for any ORM tool according to your use case. Not familiar with morphia. I guess hibernate is for RDBMS only. Hibernate OGM is for NoSQL databases.
For example, You can use Kundera if you want to query in JPA way like in RDBMS databases. It's an open-source object mapper for NoSQL databases supporting MongoDB, Cassandra, HBase, ONS, etc. It takes query in JPA format like
select p from Person p where p.salary > 20000

I think native is better, It seems ORM with Mongodb contains restrictions, (e.g, using eclipse-link you could not directly persist Map)

Database first ORM for Play Framework (Java) with auto DB model generating

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.

Hibernate and SQL portability

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.

Targeting a Java app at Oracle AND Postgres

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.