Which is the best JPA practice in a production environment? - jpa

I have seen instances where developers create tables in the database then they use jpa tools to generate entities from the tables. There are also cases where entities are first created then the tables will be created by the JPA provider. Which is the best approach?
When I learnt java ee web I used the jpa provider to create entities for me in the database.

Both approaches work. This poll by JPA Buddy shows that 56% of developers manage their data model in the database and then synchronize DB tables with JPA entities, while 44% develop the data model as JPA entities and update the database in accordance with modifications in Java code.
So, there is no right answer to your question. If you fully control your database you can follow any path you prefer. Note, that JPA tools will fully regenerate your classes. You can use IntelliJ IDEA you can use JPA Buddy which provides a cherry-pick way to upgrade your entities.
If you follow the entity first approach, you will need to upgrade your database accordingly using some DB versioning framework like Flyway or Liquibase. Make sure you don't use auto-dll by hibernate in production as it is explained in this tutorial.
If you are given the database, you have no option other than reverse engineer tables into entities.

Related

Using Different Database Providers for Development vs Production with JPA

I have seen some documentation on connecting to more than one database/data source via JPA, but this is not what I want to do exactly. I want to use one database provider for development and a completely different database provider for production (and probably QA). This question would also be applicable to supporting different production environments with different database providers (ie, DB2 for Client 1, Oracle for Client 2, MySQL for Client 3, etc).
In my case, I would like to do the following:
use JPA with Apache Derby for development purposes
use JPA with IBM DB2 for production purposes
We do not use Spring :(
With MyBatis, I could simply provide XML mappings for each database I wanted to support. And map all of results back to the same entities/POJOs.
So far it seems to me, that JPA will require custom everything up to maybe the Service layer (with entities, DAO, sql all being custom per database).
I want to know how you would go about setting up your application to use Derby for development and DB2 for production. Can I get by with using the same entities for both, should I separate the DAO layer into separate projects, can I use one persistence.xml, etc.?
Please let know what approach you would suggest to accommodate this.
This is a pretty common scenario, you don't need to duplicate anything if you are using JPA properly. You can use the same #Entity classes and DAOs.
If you are using Maven you can make the connection settings specific to some Maven profile, e.g. create profile for each environment and then let Maven resource filtering populate properties in your persistence.xml file (see this answer).

JPA for Graphdatabases

I thought about using a graph database for my new project. It's
a project with many social relations and many other things which
can easily be represented by a graph.
Graph-Databases are much faster so I started thinking about it.
However, I have a Java Enterprise Web Application and I have been using
(until now) a relational MySQL Database with JPA.
Now my question: Is there already the same JPA functionallity
for Graph-Databases like there is for relational Databases?
I would like to use Neo4j or OrientDB.
DataNucleus JPA provides persistence to Neo4j. Supports basic relationships and an amount of Cypher query capabilities, and there is a tutorial for use with JPA (as well as JDO). Open to contributions to push it further.
OrientDB also provides an amount of support for JPA annotations direct IIRC.

Is it feasible to build company specific framework that wraps NHibernate?

I heard that companies that use Java technologies, they used to build their own custom Framework that wraps Hibernate. However, is it really feasible for their .Net peers to do the same thing with NHibernate or Entity Framework?
This is almost always a horrible idea - I think Ayende sums it up best in this article. In general, you should consider NHibernate itself to be the "wrapper" around your data access - attempting to build an abstraction layer on top of it is probably going to be a losing proposition.
Actually, you should check out some of the articles on .NET Junkie's weblog. He wrote several great posts on how to deal with repositories, queries, commands and so on. We've been using these in a very large enterprise system where we switch between an in-memory dictionary, an in-memory SQLite database and a production environment using SQL Server or Oracle. Obviously, we use NHibernate for this.
I use the repository pattern and a separate project/dll to abstract away the data framework nhibernate / entity framework. this is a good starting point http://codebetter.com/petervanooijen/2008/04/04/wrapping-up-nhibernate-in-repositories/

EF 4.1 model first code generation tool or template

Is there a template or tool to generate code from the database directly? I want to use model first scenario but do not want .edmx file for mappings. There is a database with many tables and I do not want to write all the classes (I am lazy) for that. So, is there a template to generate the code and set the annotations/use fluent api for defining the relationships, etc automatically from the existing database?
This would be helpful in the following scenario as well. Say, I was using .edmx with POCOs and now I do not want the mappings in the .edmx file. I want the mappings in the code. It would be great to have a tool or a template to generate the mappings in the code from the existing database.
I am starting on learning EF 4.1. I think "Code first becomes model first in version 2 i.e. after the database is created/released (in version 1) and needs some changes". Is that really true? I'd love to hear some comments. Thanks.
Check out the 'Reverse Engineer Code First' feature of the EF Power Tools CTP1 that was just released.
For generating classes, you can use POCO t4 template generation. Have a look at this detailed link which will help you getting started. That way you will get all the classes generated.
For mapping, you can use Code-Only style for Entity Framework but generating classes and context using POCO template will have far more advantage over creating the mapping yourself. Imagine adding new tables or modifying the tables, it will involve more work. But I will certainly love to know if there is any mapping tool for that.
It is possible that you are using EF-provider Devart dotConnect for Oracle when working with Oracle database. In this case the following information will help you to choose the tool.
The first version of Entity Framework Power Tools also contained the capability of generating a Code-First model with fluent mapping from an existing database. Although useful, this functionality is limited as regards its flexibility: the developer can only set the connection string; following that, classes are generated from all database objects available to the user. That is not extremely convenient, since in Oracle, for example, numerous schemas containing hundreds and sometimes thousands of tables are available to the user.
Rather than resort to this limited functionality, the users of Devart ADO.NET providers can avail themselves of impressively robust design-time development capabilities of Entity Developer, an EF-designer delivered with Devart providers. Also possible is the choice between the Database-First approach, as provided in EF Power Tools, and the Model-First approach, within which Code-First classes are created in the EDM-designer.
When compared to EF Power Tools, the Database-First approach to the development of EF Code-First models also allows selecting objects that must be available in the model, setting naming rules for the generation of class names and properties and so on. Besides, the resulting model can be modified and improved in the designer.
To better meet developers' needs, Code-First code generation in Entity Developer both for C# and VB is based on the T4-template that is easily accessible and can be modified in feature-rich T4 Editor contained in Entity Developer.
For more information on Code-First development in Entity Developer, see "Entity Developer – EF Code First DbContext Template"
http://www.devart.com/blogs/dotconnect/index.php/entity-developer-ef-code-first-dbcontext-template.html

Difference between JPA and JDO?

want to develop my project on Google App Engine .I want to use google big table as database. For the database I have two options JPA and JDO. Will you guys please suggest me on it? Both are new for me and I need to learn them. So I will be focused on one after your replies.
Since you're using Data Nucleus, see their FAQ on JDO vs JPA. http://www.datanucleus.org/products/accessplatform_3_0/jdo_jpa_faq.html
DataNucleus AccessPlatform supports both JDO and JPA specifications of Java persistence. As such it has no "vested interest" in either technology, believing that it is for users to choose which they like best. There has been much FUD on the web about JDO and JPA, largely perpetrated by RDBMS vendors. This FAQ corrects many of these points
A key difference is that JDO support a rich domain model (logic together with data), in fact all persistent classes can have a reference to the current PersistenceManager, issue queries, and, I guess, it's possible not to have fields persistent by default.
JPA does not support such software design. In fact each Entity doesn't have a reference to the PersistenceManager, to have it you have to resort to ThreadLocal variables, which is not a very elegant and robust solution.
Since GAE BigTable is not an RDBMS, JDO is a better choice. There are some detailed comparision articles in Aphache JDO, it is helpful for me.
JPA persists java objects to relational data via ORM, while JDO is more general specification for java object persistence. So using JDO will give you more freedom in storage implementation options for your objects.
JPA is the leading java standard for persistence. So I'll say use JPA if you are using RDBMS and require ORM.
Hibernate is generally used as JPA implementation. If you need some extra features you can use hibernate specific annotations.
This question already looks to be discussed here JDO vs JPA for Java on Google App Engine