We Keep Coding

Oracle procedure to java batch

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.

Hibernate OGM with mongodb in an enterprise solution

I wanted to ask you, if you have any experience that Hibernate OGM works as much fine with mongodb, that it could be used in an enterprise solution without any worries. With other words - does this combination work as fine as for example Hibernate ORM with MySQL and is is also that easy to set up? Is it worth to use it - meant the level of afford needed to set it up compared to the level of improvement of the work with the database? Would you prefer another OGM framework or even don't use any? I read about it some time ago, but it was in the early stages of this project and didn't work too well yet. Thanks for advices and experiences.

(Disclaimer: I'm one of the Hibernate OGM authors)
With other words - does this combination work as fine as for example Hibernate ORM with MySQL?
The 4.1 release is the first final we consider to be ready to use in production. The general user experience should be not much different from using the classic Hibernate ORM (which still is what you use under the hood when using Hibernate OGM). Also the MongoDB dialect probably is the one we put most effort in, so it is in good shape.
But as Hibernate OGM is a fairly young project, of course there may be bugs and glitches which need to be ironed out. Feature-wise, there are some things not supported yet (e.g. secondary tables, criteria API, more complex JPA queries), but you either shouldn't really need those in most kinds of applications or there are work-arounds (e.g. native queries).
and is is also that easy to set up?
Yes, absolutely. The set-up is not different from using Hibernate ORM / JPA with an RDBMS. You only use another JPA provider class (HibernateOgmPersistence) and need to set some OGM-specific options (which NoSQL store to use, host name etc.). Check out this blog post which walks you through the set-up. For store-specific settings (e.g. how to store associations in document stores) there is an easy-to-use option system based on annotations and/or a fluent API.
[Is it worth the effort] to set it up compared to the level of improvement of the work with the database?
I don't think there is a general answer to that. In many cases object mappers like Hibernate ORM/OGM are great, in others cases working with plain SQL or NoSQL APIs might be a better option. It depends on your use case and its specific requirements. In general, OxMs work well if there is a defined domain model which you want to persist, navigate its associations etc.
Would you prefer another OGM framework
I'm obviously biased, but let me say that using Hibernate OGM allows you to
benefit from the eco-system existing around JPA/Hibernate, be it integration with other libraries such as Hibernate Validator or Hibernate Search (or your in-house developed Hibernate-based API) or tooling such as modelling tools which emit JPA entities.
work with different NoSQL backends using the same API. So if chances are you need to integrate another NoSQL store (e.g. Neo4j to run graph queries) or an RDMBS, then Hibernate OGM will allow you to do so easily.
I read about it some time ago, but it was in the early stages of this project
Much work has been put into Hibernate OGM over the last year, so my recommendation definitely is to try it out and see in a prototype or spike how it works for your requirements.
If you have any feature requests or questions, please let us know and we'll see what we can do for you.

Custom JPA implementation // existing No SQL JPA implementations

Background:
I've been using JPA lately, and I am very impressed by how easily I was able to produce a persistence layer for a reasonably large relational database project.
We use a lot of no-sql databases at my company, specifically column oriented ones. I have some questions about potentially using JPA for those databases:
Questions
Can JPA be used with NO-SQL databases? It stands to reason that if the framework can generate a query for a SQL database and map the results, then it probably could reasonably easily be tailored to generate a different kind of query and a different mapping, for say, querying Hadoop maybe?
If it's possible, are there any existing implementaitons of JPA that use things besides SQL?
Are there any good resources on implementing/extending JPA? I realize TSQL, PLSQL, etc. must all be specifically addressed in JPA, so there must be an extensibility mechanism we can manipulate.

There are various JPA implementations that support (the badly termed) "NoSQL" set of datastores. The most complete we've found to be DataNucleus which also provides the more suitable JDO API also. It supports MongoDB, Cassandra, HBase, AppEngine, LDAP, spreadsheets, Neo4j, and some others

As per your question i came across Hibernate OGM which stands for Hibernate Object Grid Mapper which provides JPA (java Persistence api)the support for the NoSQL solutions.
Hibernate OGM has the following capabilities : -
persists entities into a NoSQL
datastore specific native queries
full-text queries, using Hibernate Search as indexing engine
I haven't explore more on this framework OGM but looks very promising solution for your questions.
You can refer to the following URL to get more idea about the Hibernate OGM
http://hibernate.org/ogm/

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.

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.