We Keep Coding

JPA - What exactly does it mean for an entity object to persist? What is the definition of persistence?

I'm fairly new to java web applications and I am undertaking the task of learning JPA. However, it is not explicitly clear what it means for an entity object to persist. I think I have an idea, but I would rather not assume its meaning.
I am referencing the Oracle JPA Doc, but they continue to use the words like "persist" or "persistence" when describing persistent fields/properties. Can someone shed some light on this idea of persistence? And maybe define what it means for an instance of an entity to be persistent?
And if you could not use the word "persistent" (or any form of the word) in your definition that would be much appreciated. A simple answer would be great, but more in-depth explanations are definitely welcome! Thanks so much!

Persistence simply means to Store Permanently.
In JAVA we work with Objects and try to store Object's values into database(RDBMS mostly).
JPA provides implementation for Object Relation Mapping(ORM) ,so that we can directly store Object into Database as a new Tuple.
Object, in JPA, are converted to Entity for mapping it to the Table in Database.
So Persisting an Entity means Permanently Storing Object(Entity) into Database.
Hope this Helps!!

"Persist" means "lives on after the application is shut down". The object is not just in volatile memory; it's in more permanent storage on disk. If the application is shut down, or the user ends their session and begins a new one, the old data is still available from permanent storage on disk.
Databases store information on disks, unless they are in-memory versions that give you the advantage of using SQL but little else. If you use a relational SQL database, you get a query language that makes it easy to Create/Read/Update/Delete information without having to worry about how it's stored on the disk.
SQL databases store relations on disk using different data structures (e.g. B-Tree). Relations are defined in terms of tables and columns. Each record in a table consists of a tuple of row values. Objects have to map tables and columns to objects and attributes using object-relational mapping. JPA generalizes this idea and builds it into Java EE, following the example of implementations like TopLink and Hibernate.
NoSQL databases, like MongoDB, also store information on disk as documents rather than relations.
Object databases serialize an object and all its children using formats like Java serialization, XML, JSON, or custom formats (e.g. Google protocol buffers).
Graph databases, like Neo4J, can be thought of as more general cases of object databases.

Java object references in a database [duplicate]

I don't know if this is the right title for this question.
Anyway, recently I have heard about that you could make life easier when creating database. By in which you use object based database. It will make migration to other type of database also easier e.g. from MySQL to SQLlite or something else.
Anyway the main way I do a webpage with database access now is that I manually write down the Query to fetch what I need from a database. However it can be done in some other way also which does not involve I have to write query. I want to know how this other method work. How to search it in Google.

Object DB
High performance
Faster as no joins required
Inherent versioning mechanism
Navigational interface for operations (like graph traversal)
Object Query Language retrieve objects declaratively
complex data types
object identity ie. equals() in which object identity is independent of value and updates
facilitates object sharing
classes and hierarchies (inheritance and encapsulation)
support for relationships
integrated with a persistence language like ODL
support for atomicity
support for nested relationships
semantic modelling
Cons
No mathematical foundation as RDB (refer Codd)
cons of object orientation
persistence difficult for complex structures, some data must be transient
Object-Relational databases (You might have seen UDTs!)
support for complex data types like collection, multisets etc
object oriented data modelling
extended SQL and rich types
support for UDT inhertance
powerful query language
Different approaches (OO, Relational DB or OODB) may be necessary for different applications
References
OODMS manifesto
ODMG
The Object-Oriented Database System Manifesto
Object Oriented Database Systems
Object Relational Databases in DBMS
Completeness Criteria for Object-Relational Database Systems
Comparisons
http://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems
http://en.wikipedia.org/wiki/Comparison_of_object-relational_database_management_systems

It sounds like you are talking about JPA. You simply annotate your objects, and the database is setup according to the objects for you. The most used JPA implementation is Hibernate, and is very quick way of writing database enabled Java applications.
If you want more control over the database structure, you can do that via the annotations.
For more information on hibernate, check out http://www.hibernate.org/.

If you are using an object oriented database, you are not using a relational database like MySQL or SQLite.
Instead, the database directly stores your application objects, and you usually can query these with some query language or API.
I have only experience with db4o, there you simply do
database.store(object);
and your object is stored.

Java EE Design Assistance Required

I am using MVC pattern in my web application. In which I have three layers
Control Layer
Manager Layer
Dao Layer
And I am using DTOs from control layer to manger and then to Dao layer and same as opposite.
My question is that what is the main purpose of DTO?
Can I use DTOs to map our relational database table or should I go with 'Bean'?
If I use DTOs between layers then how can I represent a database table in an object because DTOs among layers can contain properties which are not related to the database table.

There is no problem in using DTOs and map them to your database tables. But you'll have to do the mapping by yourself (using JDBC, Spring JDBC, etc).
Another option is to use an ORM to do the mapping of your DTOs to database. You can even create properties that are not mapped to your tables. Take a look at JPA.
The choice between those two options is something personal. The first will be more laborous at first, while the second option have a bigger learning curve. If you are well versed into SQL, I would go with JDBC.

My question is that what is the main
purpose of DTO?
The main purpose of a DTO is to transmit data between two layers. It has no real functionality other than to act as a basket for shipping data.
That's why they call it a Data Transfer Object.
Can i use DTO's to map our relational
database table or should i go with
'Bean'?
Whether you decide to use JavaBean formatted accessors or your own accessors really doesn't matter with a DTO. Both sides of the transfer must be in agreement; but, if you have a setName(...) setter or a name(...) setter it will not affect functionality.
Although it may not matter in a functionality sense, it is best to stick to established naming conventions for ease of revisiting the code and lack of confusion when training new maintainers. Also, a few libraries might assume you are using bean conventions (or require them). If you are uncertain, best to stick with standard JavaBean conventions, as your new conventions are probably not as tested (or as formal).
If i use DTO's between layers then how
can i represent a database table in
object because DTO's among layers can
contain properties which are not
related to database table.
DTOs have nothing to do with database tables. Don't make your DTO look like your database table unless it's the most natural thing to do.

The main purpose of DTO's is to reduce the overhead when transferring data across layers.
If you didnt have a DTO, what you would have is a class containing data as well as logic which would be getting passed across layers. Using DTO's ensures that you pass only what is needed i.e the data across layers.
Definitely, you do have the option of mapping your DTO's to your database tables and having the bean design which more closely represents the domain objects.
That is one way of doing it.
Conversely, depending on your database design, your DTO's could be more in line with your actual business entities - just without the logic

My question is that what is the main
purpose of DTO?
Like the expansion (Data Transfer Object) implies, DTOs are meant to transfer structured data across various tiers. DTOs enable you to decouple the protocol specific implementations that represent data, so that data from different sources can be abstracted before communication across tiers.
For example, DTOs will allow you to decouple the data present in a HttpServletRequest object from its internal storage, so that you can send the data to a service in the business logic layer. The same applies for DTOs used to abstract the results obtained from a SQL query and residing in a ResultSet object. In short, DTOs allow you to transmit data without holding onto the source - you can forget about the HTTP response and the JDBC connections, while you work on the data.
Can i use DTO's to map our relational
database table or should i go with
'Bean'?
You can adopt the second approach of using Beans. In fact, with JPA you do not require your DTOs at all. The JPA managed beans themselves represent data in various tables, and can be de-linked from the database state, so that you can use them for data transmission.
If i use DTO's between layers then how
can i represent a database table in
object because DTO's among layers can
contain properties which are not
related to database table.
That depends on how you want to couple the DTO with the database table. It is preferable to have a one-to-one mapping between the DTO and the database table, and choose another DTO for the purpose of transmitting properties not related to the table. After all, DTOs like every other object should have a single responsibility. If the responsibility is to reflect a database table, then it should contain other "irrelevant" properties.
To extend the recommendation of using JPA in this context, it is poor design to have unrelated attributes in a JPA entity, especially when that unrelated attribute should be marked as transient and adds no value to the behavior of the entity.

Will hibernate java programs have no sql code?

I haven't worked with hibernate. I have little bit of experience in java. I was going through source of a beast of an java application created by Oracle(Retail Price Management). I was expecting a lot of sql code embedded in there as the application makes heavy use of database. But to my surprise, NO embedded SQL code! so far. I found that it was using what is called as "Hibernate" from the lot of .hbm.xml files. Is it a trademark for java programs using hibernate or maybe I haven't seen the complete codebase?. Could someone enlighten me how this is possible?. Thanks.

Hibernate, as all ORM tools, indeed lessens or eliminates the need to use raw SQL in Java code, due to the following:
many associations between various entities are recorded in the Hibernate mapping, so these are fetched automatically by Hibernate - i.e. if you have an aggregation relationshiop between two classes on the Java side, this may be mapped as a foreign key relationship in the DB, and Hibernate, whenever an instance of class A is loaded, can automatically load the associated instances of class B too,
many queries can be done in Hibernate's own HQL query language, or using its Criteria API.
Under the hood Hibernate does generate SQL to communicate with the DB, but this is not visible on the Java side. It can be seen in the logs though, if it is enabled.
Due to this, programs using Hibernate very rarely need to use JDBC or SQL directly. The exceptions are typically ralted to "tricky" legacy DB schemas which can't be fully handled by Hibernate.

Because that's the whole purpose of using Hibernate or any other object-relational mapping framework.
Hibernate solves object-relational impedance mismatch problems by replacing direct persistence-related database accesses with high-level object handling functions.

Hibernate generates SQL for all its standard database operations. It understands different SQL dialects, and the mapping files (.hbm.xml) tell it about the database structure so it knows how to construct its queries. There is a showSql setting you can turn on if you want to see it outputting its generated SQL as it runs.

Hibernate is an Object-Relational Mapper (ORM). ORMs are used to hide the ugly details of SQL incompatibility[sic] between databases from your program -- you define your tables and map them to an object hierarchy (the .hbm.xml files) and then Hibernate does the rest. Thus most programs that use Hibernate won't see a single phrase of SQL, unless there's a specific reason to execute a complicated query.

Hibernate is a tool, or technology that takes care of the interaction between the database and application for you. You have to tell the structure of the application and the database to it, this is what is in the .hbm.xml files.
The SQL is generated by Hibernate at runtime (kind of)
Say you have an Fruit class, and objects of this is persisted into a T_FRUIT table.
You say this to hibernate, via the .hbm.xml files. That there is a table T_FRUIT, this table is represented by the Fruit class, and which fields in the Fruit class correspond to which columns in th T_FRUIT table.
And then it knows whenever you are trying to save a fruit, it should insert/update to the T_FRUIT table.
When you want to create an Apple, you create an object of fruit corresponding to apple and save "save this fruit".
Hibernate takes care of persisting it.
You can have relationships defined between tables, and Hibernate is intelligent enough to persist in multiple tables.
When you fetch a fruit, hibernate fetches the details of the fruit and its children also(data from referencing tables). And you can say whether you want fetch all the children
at once, or as and when required.
And so on. Aim is to make your life easier, and code maintainable, easy to read, portable,...
With this info, let me redirect you.

ORM Technologies vs JDBC?

My question is regarding ORM and JDBC technologies, on what criteria would you decide to go for an ORM technology as compared to JDBC and other way round ?
Thanks.

JDBC
With JDBC, developer has to write code to map an object model's data representation to a relational data model and its corresponding database schema.
With JDBC, the automatic mapping of Java objects with database tables and vice versa conversion is to be taken care of by the developer manually with lines of code.
JDBC supports only native Structured Query Language (SQL). Developer has to find out the efficient way to access database, i.e. to select effective query from a number of queries to perform same task.
Application using JDBC to handle persistent data (database tables) having database specific code in large amount. The code written to map table data to application objects and vice versa is actually to map table fields to object properties. As table changed or database changed then it’s essential to change object structure as well as to change code written to map table-to-object/object-to-table.
With JDBC, it is developer’s responsibility to handle JDBC result set and convert it to Java objects through code to use this persistent data in application. So with JDBC, mapping between Java objects and database tables is done manually.
With JDBC, caching is maintained by hand-coding.
In JDBC there is no check that always every user has updated data. This check has to be added by the developer.
HIBERNATE.
Hibernate is flexible and powerful ORM solution to map Java classes to database tables. Hibernate itself takes care of this mapping using XML files so developer does not need to write code for this.
Hibernate provides transparent persistence and developer does not need to write code explicitly to map database tables tuples to application objects during interaction with RDBMS.
Hibernate provides a powerful query language Hibernate Query Language (independent from type of database) that is expressed in a familiar SQL like syntax and includes full support for polymorphic queries. Hibernate also supports native SQL statements. It also selects an effective way to perform a database manipulation task for an application.
Hibernate provides this mapping itself. The actual mapping between tables and application objects is done in XML files. If there is change in Database or in any table then the only need to change XML file properties.
Hibernate reduces lines of code by maintaining object-table mapping itself and returns result to application in form of Java objects. It relieves programmer from manual handling of persistent data, hence reducing the development time and maintenance cost.
Hibernate, with Transparent Persistence, cache is set to application work space. Relational tuples are moved to this cache as a result of query. It improves performance if client application reads same data many times for same write. Automatic Transparent Persistence allows the developer to concentrate more on business logic rather than this application code.
Hibernate enables developer to define version type field to application, due to this defined field Hibernate updates version field of database table every time relational tuple is updated in form of Java class object to that table. So if two users retrieve same tuple and then modify it and one user save this modified tuple to database, version is automatically updated for this tuple by Hibernate. When other user tries to save updated tuple to database then it does not allow saving it because this user does not have updated data.

Complexity.
ORM If your application is domain driven and the relationships among objects is complex or you need to have this object defining what the app does.
JDBC/SQL If your application is simple enough as to just present data directly from the database or the relationships between them is simple enough.
The book "Patterns of enterprise application architecture" by Martin Fowler explains much better the differences between these two types:
See: Domain Model and Transaction Script

I think you forgot to look at "Functional Relational Mapping"
I would sum up by saying:
If you want to focus on the data-structures, use an ORM like JPA/Hibernate
If you want to shed light on treatments, take a look at FRM libraries: QueryDSL or Jooq
If you need to tune your SQL requests to specific databases, use JDBC and native SQL requests
The strengh of various "Relational Mapping" technologies is portability: you ensure your application will run on most of the ACID databases.
Otherwise, you will cope with differences between various SQL dialects when you write manually the SQL requests.
Of course you can restrain yourself to the SQL92 standard (and then do some Functional Programming) or you can reuse some concepts of functionnal programming with ORM frameworks
The ORM strenghs are built over a session object which can act as a bottleneck:
it manages the lifecycle of the objects as long as the underlying database transaction is running.
it maintains a one-to-one mapping between your java objects and your database rows (and use an internal cache to avoid duplicate objects).
it automatically detects association updates and the orphan objects to delete
it handles concurrenty issues with optimistic or pessimist lock.
Nevertheless, its strengths are also its weaknesses:
The session must be able to compare objects so you need to implements equals/hashCode methods
But Objects equality must be rooted on "Business Keys" and not database id (new transient objects have no database ID!).
However, some reified concepts have no business equality (an operation for instance).
A common workaround relies on GUIDs which tend to upset database administrators.
The session must spy relationship changes but its mapping rules push the use of collections unsuitable for the business algorithms.
Sometime your would like to use an HashMap but the ORM will require the key to be another "Rich Domain Object" instead of another light one...
Then you have to implement object equality on the rich domain object acting as a key...
But you can't because this object has no counterpart on the business world.
So you fall back to a simple list that you have to iterate on (and performance issues result from)
The ORM API are sometimes unsuitable for real-world use.
For instance, real world web applications try to enforce session isolation by adding some "WHERE" clauses when you fetch data...
Then the "Session.get(id)" doesn't suffice and you need to turn to more complex DSL (HSQL, Criteria API) or go back to native SQL
The database objects conflicts with other objects dedicated to other frameworks (like OXM frameworks = Object/XML Mapping).
For instance, if your REST services use jackson library to serialize a business object.
But this Jackson exactly maps to an Hibernate One.
Then either you merge both and a strong coupling between your API and your database appears
Or you must implement a translation and all the code you saved from the ORM is lost there...
On the other side, FRM is a trade-off between "Object Relational Mapping" (ORM) and native SQL queries (with JDBC)
The best way to explain differences between FRM and ORM consists into adopting a DDD approach.
Object Relational Mapping empowers the use of "Rich Domain Object" which are Java classes whose states are mutable during the database transaction
Functional Relational Mapping relies on "Poor Domain Objects" which are immutable (so much so you have to clone a new one each time you want to alter its content)
It releases the constraints put on the ORM session and relies most of time on a DSL over the SQL (so portability doesn't matter)
But on the other hand, you have to look into the transaction details, the concurrency issues
List<Person> persons = queryFactory.selectFrom(person)
.where(
person.firstName.eq("John"),
person.lastName.eq("Doe"))
.fetch();

It also depends on the learning curve.
Ebean ORM has a pretty low learning curve (simple API, simple query language) if you are happy enough with JPA annotations for mapping (#Entity, #Table, #OneToMany etc).