I'm about to start developing a dynamic web application with Java (i.e., Servlets and JSP).
Obviously I will need to keep a database with all sorts of information (Users, etc.). My question is - is there a good library for saving/storing/retrieving from a database for this kind of application?
I don't mean JDBC, which is used to send queries and parse results, but some sort of abstraction for saving and loading my object to/from the database.
Currently, I am trying to develop some sort of generic classes for handling of these cases in django style (i.e., classes have a save() method), but since these are generic, I suppose something ought to exist already.
It sounds like you are looking for an Object Relational Mapping (ORM) tool. ORMs map rows in a table to objects in your code. In fact, what you have been using in Django is an ORM.
Hibernate is one such ORM that will let you describe how your Java objects should be mapped.
Related
Nowadays typical JAVA application can expose some JPA entities via REST easily. In that case in short there is e.g. persistence.xml where driver, database, etc are defined to access the database and persistence unit easily can be used in the application.
I am looking for something opposite. I.e. if somebody saw the solution where persistence relays on REST API?
Background of my question is the following.
There is an app written in some ancient technology and there is quite complex logic behind. I would like to build new JEE JPA (Eclipselink if possible) based application which could (at least for some time) use that complex logic in order to find and read data. My idea was to implement REST interface on top of old application and let the new one use REST queries in order to deal with the data. Since logic is complex I would like to avoid duplicating it and maintaining 2 branches of code in different technologies until I am fully prepared to move all stuff into modern technology.
Do you think it is possible?
You can design your Data Access Layer and the rest of your new application so that it doesn't care how the data is stored (no "bad" dependencies).
You would then need to create separate versions of the DAL, where one would fetch the data from the legacy REST app and one would use JPA. This will make it possible to start out being dependent on the legacy app, and part by part build the JPA DAL to retrieve data from a database.
We have an application thats already running for a long time. Now we are migrating it to Spring and possibly using Hibernate or any other ORM.
But we caught up with a question. Is it not recommended / bad idea to use Hibernate for the already existing Database and model the object around Schema?
Most people advocate NOT using Hibernate and instead of go with some other ORMs like iBatis. But in our company, all are proponents of Hibernate.
Any experiences?
I would say that it's irresponsible to choose Hibernate, iBatis, or anything else without knowing your requirements.
If you don't have a solid object model, I'd say that Hibernate is a terrible choice.
If you use stored procedures as the interface to your database, I'd say that Hibernate is a terrible choice.
If you don't like the dynamic SQL that Hibernate generates for you, I'd say that Hibernate is a terrible choice.
Get it? Knee-jerk reactions like the ones from those Hibernate proponents aren't a good idea.
It might be that iBatis or Spring JDBC template is a better choice than Hibernate. You ought to become more informed about that decision and make it for your application rather than blindly listen to a mob.
You don't have to be all or none about it, either. It's possible to implement part of your solution with one technology and the rest in another.
I'd recommend making your persistence layer interface-based so you can swap implementations without affecting clients.
I recommend looking at SansORM (a NoORM object mapper). It is designed for SQL-first development, which fits well with retrofitting an existing schema.
Hibernate works well if you can model your database under your objects.
Vice versa, you are likely to get the database model as your your domain model. You need to evaluate how distant those two models are, otherwise you are going to map the database => ORM objects => your domain model. I would avoid that.
If I want to skip the ORM part, I find myself quite happy with JDBI which I prefer over Spring JDBC Template
As others have pointed out an ORM is only a good choice if your database is not far from an object model.
If that is the case then an option would be Hibernate through JPA for two resons:
Netbeans has a tool to generate JPA Entities from an existing database. This entities are not dependant on Netbeans so you could use a different IDE after the initial reverse engineering.
Spring Data JPA can avoid writing trivial queries and focus on the hard ones.
I am learning Java EE and I downloaded the eclipse with glassfish for the same. I saw some examples and also read the Oracle docs to know all about Java EE 5. Connecting to a database was very simple. I opened a dynamic web project, created a session EJB , I used EntityManager and with the get methods could access the stored data table.
For my next project I had create a simple class and then access some DB table. The very first problem I encountered was that the PersistenceUnit attribute would only be recognized by EJB,Servlet etc and not a simple java class. So then I could not use the EntityManager way(or can I?)
I was asked to go via the "JDBC" way. The very first problem I encountered was to get the connection to the DB. It seems all this must be hardcoded. I had a persistence.xml with which I could easily configure the data base connection. Even setting up a driver for the DB was easy. Also there no get/set methods in the JDBC for accessing table entities.
How do I understand JPA and persistence in relation to JDBC? What was JPA thought for? Why is there set/get methods? Can someone throw some light on the essence of these two and what are the pros/cons without "jargons"?? Please also suggest some links. A simple google search for JPA and JDBC differences led me to some sites full of "terminology" I couldn't follow :(
In layman's terms:
JDBC is a standard for Database Access
JPA is a standard for ORM
JDBC is a standard for connecting to a DB directly and running SQL against it - e.g SELECT * FROM USERS, etc. Data sets can be returned which you can handle in your app, and you can do all the usual things like INSERT, DELETE, run stored procedures, etc. It is one of the underlying technologies behind most Java database access (including JPA providers).
One of the issues with traditional JDBC apps is that you can often have some crappy code where lots of mapping between data sets and objects occur, logic is mixed in with SQL, etc.
JPA is a standard for Object Relational Mapping. This is a technology which allows you to map between objects in code and database tables. This can "hide" the SQL from the developer so that all they deal with are Java classes, and the provider allows you to save them and load them magically. Mostly, XML mapping files or annotations on getters and setters can be used to tell the JPA provider which fields on your object map to which fields in the DB. The most famous JPA provider is Hibernate, so it's a good place to start for concrete examples.
Other examples include OpenJPA, toplink, etc.
Under the hood, Hibernate and most other providers for JPA write SQL and use JDBC to read and write from and to the DB.
Main difference between JPA and JDBC is level of abstraction.
JDBC is a low level standard for interaction with databases. JPA is higher level standard for the same purpose. JPA allows you to use an object model in your application which can make your life much easier. JDBC allows you to do more things with the Database directly, but it requires more attention. Some tasks can not be solved efficiently using JPA, but may be solved more efficiently with JDBC.
JDBC is a much lower-level (and older) specification than JPA. In it's bare essentials, JDBC is an API for interacting with a database using pure SQL - sending queries and retrieving results. It has no notion of objects or hierarchies. When using JDBC, it's up to you to translate a result set (essentially a row/column matrix of values from one or more database tables, returned by your SQL query) into Java objects.
Now, to understand and use JDBC it's essential that you have some understanding and working knowledge of SQL. With that also comes a required insight into what a relational database is, how you work with it and concepts such as tables, columns, keys and relationships. Unless you have at least a basic understanding of databases, SQL and data modelling you will not be able to make much use of JDBC since it's really only a thin abstraction on top of these things.
JDBC is the predecessor of JPA.
JDBC is a bridge between the Java world and the databases world. In JDBC you need to expose all dirty details needed for CRUD operations, such as table names, column names, while in JPA (which is using JDBC underneath), you also specify those details of database metadata, but with the use of Java annotations.
So JPA creates update queries for you and manages the entities that you looked up or created/updated (it does more as well).
If you want to do JPA without a Java EE container, then Spring and its libraries may be used with the very same Java annotations.
The difference between JPA and JDBC is often the deciding factor, as the two database technologies take very different approaches to work with persistent data. JDBC, allows developers to construct database-driven Java programs utilizing object-oriented semantics
JPA is database-agnostic, meaning that the same code can be used in a variety of databases with few modifications. JPA serves as a layer of abstraction that hides the low-level JDBC calls from the developer, making database coding considerably easier
hibernate is implementation of JPA
hibernate you can see further details from here about jpa Query
JDBC is a layer of abstraction on top of vendor-specific relational DB drivers. Without JDBC you would have to deal with peculiarities of a specific DB (not much fun). JDBC, however, is too low-level and entails a lot of boilerplate code.
JPA is a specification of an ORM (just an interface). It's useless without an implementation.
ORM is a kind of framework concerned with saving and retrieving objects to/from the relational DB. There are many ORMs out there with different levels of abstraction. Some of them require manually-written SQL.
Some of ORMs implement JPA (Hibernate or EclipseLink, for example). Most of them are built on top of JDBC.
Such ORMs provide the maximum level of abstraction to the point you almost never have to write SQL queries. Some people love JPA-based ORMs (they reduce boilerplate), some hate (abstraction is leaky, specification is overly complex and there are lots of corner cases).
Java analogy:
class ORM extends JDBC implements JPA {
}
Persistence layers have protocols versions so abstractions also have versions therefore you need ranges of supported versions. It is version hell
I am in need of some further information.
I am developing a small application which will be interacting with a PHP web application. The media server which we are incorporating with is extensible in Java.
I need very little access to the database inside the plugin which we are developing, I only need to view rows in about 10% of the tables. I only need to update data in 1 of the tables.
The schema as a whole is littered with foreign keys, but currently (and there is little chance this changes in the future) I do not need to modify any other information in the databse except for the one column (which is not a foreign key).
I don't really want to model all of these relationships -- as there is no need to.
What is my best bet? Will Hibernate make me map all of these domain objects? Is myBatis (formerly iBATIS) a better choice as the people I am handing off too are more comfortable with SQL? Does it matter which persistence framework I choose -- i.e. are they all going to make me model each of the tables?
These are mySQL InnoDB tables if it makes any difference.
Hibernate only requires you to map those items which you want to use within the context of your Java application. As a result, you can have objects only mapped to those tables which you desire access from the Java side.
A few caveats for the process though:
You will have to model all objects/relationships for all tables with which a given entity table will interact
Things could be messy with two programs hitting the database at the same time. While this is an issue that is accounted for and handled by Hibernate for locking, such things tend to fall by the wayside in PHP.
I can't really speak about Hibernate, but myBatis won't make you model anything - just create a POJO that contains the properties that you care about, then write mappings (in just straight sql) that map whatever columns from whatever tables you want into your pojo.
With Hibernate, you only need to model the objects you will be working with, and the ddl2hbm tool may be able to generate the Java classes for you based on the existing database, depending on if there are foreign keys linking to models you will not be using.
How does ORM work? Are objects serialized into BLOBs?
In Java, is JDO still the way to go for this? What else is available? Seems like there was a lot of talk of EJB, direct object serialization, and JDO.
To answer your first question, here is an extract from Hibernate in Action, that says that there are various ways to implement ORM:
Pure relational
The whole application, including the
user interface, is designed around the
relational model and SQL-based
relational operations. This approach,
despite its deficiencies for large
systems, can be an excellent solution
for simple applications where a low
level of code reuse is tolerable.
Direct SQL can be fine-tuned in every
aspect, but the drawbacks, such as
lack of portability and
maintainability, are significant,
especially in the long run.
Applications in this category often
make heavy use of stored procedures,
shifting some of the work out of the
business layer and into the database.
Light object mapping
Entities are represented as classes
that are mapped manually to the
relational tables. Hand-coded SQL/JDBC
is hidden from the business logic
using well-known design patterns.
This approach is extremely widespread
and is successful for applications
with a small number of entities, or
applications with generic,
metadata-driven data models. Stored
procedures might have a place in this
kind of application.
Medium object mapping
The application is designed around an
object model. SQL is generated at
build time using a code generation
tool, or at runtime by framework code.
Associations between objects are
supported by the persistence
mechanism, and queries may be
specified using an object-oriented
expression language. Objects are
cached by the persistence layer. A
great many ORM products and homegrown
persistence layers support at least
this level of functionality. It’s well
suited to medium-sized applications
with some complex transactions,
particularly when portability between
different database products is
important. These applications usually
don’t use stored procedures.
Full object mapping
Full object mapping supports
sophisticated object modeling:
composition, inheritance,
polymorphism, and “persistence by
reachability.” The persistence layer
implements transparent persistence;
persistent classes do not inherit any
special base class or have to
implement a special interface.
Efficient fetching strategies (lazy
and eager fetching) and caching
strategies are implemented
transparently to the application. This
level of functionality can hardly be
achieved by a homegrown persistence
layer—it’s equivalent to months or
years of development time. A number
of commercial and open source Java ORM
tools have achieved this level of
quality. This level meets the
definition of ORM we’re using in this
book. Let’s look at the problems we
expect to be solved by a tool that
achieves full object mapping.
ORM = Object Relational Mapping, attributes of the objects are mapped to columns in the realational database. That mapping is arbitrary, so that could be done to blobs, in practise what is most useful tends to natural mappings - Strings to Varchars, int to integers etc.
JPA is the place to look for a standard for ORM. JPA replaces the EJB CMP approach, which was found to be cumbersome. JPA allows you to express the mapping as Java annotations and also allows the mappings to be specified in configutration files, when supporting multip[le databases the latter can be useful.
JPA has a query language so that you can construct queries against object attributes.
JPA is supported by the major App Server vendors and also by products such as Hibernate.
I found JPA pretty nice to work with, more so than EJB CMP.
I would recommend still using EJB Session Beans facades for transaction mamangement and security - the annotation-based approach makes EJB 3 way easier to use than EJB 2, minimal coding overhead.
JDO is actually standard ORM too, and provides a more complete a specification than JPA (1 + 2). JPQL is more focussed on RDBMS concepts and hence mimics SQL. JDOQL follows Java syntax so is more object based. Depends if your app is ever considered to go away from RDBMS. If so then JPA is not the way to go. If it is solely for RDBMS then JPA is definitely a consideration.
Whether objects are serialized into BLOBs depends on your configuration. You can do that for complex object types if you wish, but then they won't be queryable. If you instead persist them in a native form then you can also query them, leading to more efficient apps.
--Andy (DataNucleus - JDO and JPA persistence)