Introduction Flashcards
Java Persistence 2.2 Maintenance release statement
The Java Persistence 2.2 specification enhances the Java Persistence API with support for repeating annotations; injection into attribute converters; support
for mapping of the java.time.LocalDate, java.time.LocalTime, java.time.
LocalDateTime, java.time.OffsetTime, and ava.time.OffsetDateTime types; and methods to retrieve the results of Query and TypedQuery as streams.
Definition of ORM
The technique of bridging the gap between the object model and the relational model is known as object-relational mapping, often referred to as O-R mapping or simply ORM.
why object-relational mapping?
- Objects, not tables: Applications should be written in terms of the domain model, not bound to the relational model. It must be possible to operate on and query against the domain model without
having to express it in the relational language of tables, columns, and foreign keys. - Convenience, not ignorance: It is meant for those who have an understanding of the issues and know what they need, but who don’t want to have to write thousands of lines of code to deal with a problem that has already been solved.
- Unobtrusive, not transparent: It is unreasonable to expect that persistence be transparent because an application always needs to have control of the objects that it is persisting and be aware of the
entity lifecycle. - Legacy data, new objects: It is far more likely that an application will target an existing relational database schema than create a new one. Support for legacy schemas is one of the most relevant use cases that will arise, and it is quite possible that such databases will outlive every one of us.
- Enough, but not too much: Enterprise developers have problems to solve, and they need features sufficient to solve those problems. What they don’t like is being forced to eat a heavyweight persistence model that introduces large overhead because it is solving problems that
many do not even agree are problems. - Local, but mobile: A persistent representation of data does not need to be modeled as a full-fledged remote object. Distribution is something that exists as part of the application, not part of the
persistence layer. The entities that contain the persistent state, however, must be able to travel to whichever layer needs them so that if an application is distributed, then the entities will support and not inhibit a particular architecture. - Standard API, with pluggable implementations: Large companies with sizable applications don’t want to risk being coupled to product-specific libraries and interfaces. By depending only on defined
standard interfaces, the application is decoupled from proprietary APIs and can switch implementations if another becomes more suitable.
Main challenge of ORM
the challenge in object-relational mapping is not so much the complexity of a single mapping but that there are so many possible mappings.
Samples for non mapping issues
- Because database schemas are much harder to change, should the class be forced to adopt the same storage strategy in order to remain consistent with the relational model?
- there are usually many applications, some object-oriented and some based on Structured Query Language (SQL), that retrieve from and store data into a single database. The dependency of multiple applications on the same database means that changing the database would affect every one of the applications, clearly an undesirable and potentially expensive option. It’s up to the object model to adapt and find ways to work with the database schema without letting the physical design overpower the logical application model.
The Java Persistence API consists of four areas
- The Java Persistence API
- The Java Persistence Criteria API
- The Query language
- Object-relational mapping metadata
ORM is older than Java itself
It may come as a surprise to learn that object-relational mapping solutions have been around for a long time; longer even than the Java language itself.
Two popular persistence APis at early days
The two most popular proprietary persistence APIs were TopLink in the commercial space and Hibernate in the open source community.
major advantage and disadvantage of data mappers
The biggest advantage of using a data mapping strategy like MyBatis is that the application has complete control over the SQL that is sent to the database. Stored procedures and all of the SQL features available from the driver are all fair game, and the overhead added by the framework is smaller than when using a full-blown ORM framework.
the major disadvantage of being able to write custom SQL is that it has to be maintained. Any changes made to the object model can have repercussions on the data model and possibly cause significant SQL churn during development. A minimalist framework also opens the door for the developer to create new features as the application requirements grow, eventually leading to a reinvention of the ORM wheel.
What was Java Data Objects (JDO)?
Java Data Objects (JDO) was inspired and supported primarily by the object-oriented database (OODB) vendors and never really got adopted by the mainstream programming community. It required vendors to enhance the bytecode of domain objects to produce class files that were binary-compatible across all vendors, and every compliant vendor’s products had to be capable of producing and consuming them. JDO also had a query language that was decidedly object-oriented in nature, which did not sit well with relational database users, who were in an overwhelming majority.
Few supported the specification, so JDO was talked about, but rarely used.
Sun announced that JDO would be reduced to specification maintenance mode and that JPA would draw from both JDO and the persistence vendors
and become the single supported standard going forward.
why not even just standardize on an open source product like Hibernate?
Binding a standard to an open source project like ibernate would be problematic for the standard and probably even worse for the Hibernate project.
Standardization might not be valued by the consultant or the five-person software shop, to a corporation it is huge. Software technologies are a big investment for most corporate IT departments, and risk must be measured when large sums of money are involved.
Besides portability, the value of standardizing a technology is manifested in all sorts of other areas as well. Education, design patterns, and industry communication are just some of the many benefits that tandards bring to the table.
The Java Persistence API
- The Java Persistence API is a lightweight, POJO-based framework for Java persistence.
- JPA is not a product but just a specification that cannot perform persistence by itself.
- JPA of course requires a database to persist to.
EJB 3.0 and JPA 1.0
released in 2006, ended up being divided into three distinct pieces and split across three separate documents.
- The first document contained all of the legacy EJB component model content.
- The second one described the new simplified POJO component model.
- The third was the Java Persistence API, a stand-alone specification that described the persistence model in both the Java SE and Java EE environments.
JPA 2.0
The next release, JPA 2.0, went final in 2009.
New features included:
* Additional mapping capabilities
* Flexible ways to determine the way the provider accessed the entity state
* Extensions to the Java Persistence Query Language (JPQL)
* Probably the most significant feature was the Java Criteria API, a programmatic way to create dynamic queries.
JPA 2.1
The release of JPA 2.1 was in 2013.
The JPA 2.1 specification added:
* Mapping converters
* Stored procedure support
* Unsynchronized persistence contexts for improved conversational operations.
* It also added the ability to create entity graphs and pass them to queries, amounting to what are commonly known as fetch group constraints on the returned object set.
