Retrieving Objects

On the database server side object retrieval results in a more expensive operation: A query for root class instances ofinherit.joined.v1.BillingDetails ❶ of our inheritance hierarchy results in joining all three tables BillingDetails ❶, BankAccount ❷ and CreditCard ❸:

Java 
package inherit.joined.v1;
	      ...
	      public class RetrieveAll {
	      ...
	      final Query searchBilling = session.createQuery("from inherit.tpc.v1.BillingDetails" ❶);
	      ...
Sql 
Hibernate: 
	      select
              billingdet0_.id as id0_,
              billingdet0_.created as created0_,
              billingdet0_.number as number0_,
              billingdet0_1_.bankName as bankName1_,
              billingdet0_1_.swiftcode as swiftcode1_,
              billingdet0_2_.cardType as cardType2_,
              billingdet0_2_.expiration as expiration2_,
              case 
              when billingdet0_1_.id is not null then 1 
              when billingdet0_2_.id is not null then 2 
              when billingdet0_.id is not null then 0 
              end as clazz_ 
	      from
              BillingDetails billingdet0_ ❶
	      left outer join
              BankAccount billingdet0_1_ ❷
              on billingdet0_.id=billingdet0_1_.id
	      left outer join
              CreditCard billingdet0_2_ ❸
              on billingdet0_.id=billingdet0_2_.id

exercise No. 22

JPA constraints and database integrity.

Q:

Explain all integrity constraints of the Hibernate generated schema. Will it implement the constraints corectly on database level corresponding to the inheritance related Java™ objects? On contrary: Are there possible database states which do not correspond to the domain model's object constraints?

A:

We take a look to the database schema:

CREATE TABLE BillingDetails (
		  id bigint(20) NOT NULL AUTO_INCREMENT PRIMARY KEY ❶,
		  created datetime NOT NULL,
		  number varchar(32) NOT NULL
		  );
		  CREATE TABLE CreditCard (
		  id bigint(20) NOT NULL  PRIMARY KEY ❷ REFERENCES ❸ BillingDetails,
		  cardType int(11) NOT NULL,
		  expiration datetime NOT NULL
		  );
		  CREATE TABLE BankAccount (
		  id bigint(20) NOT NULL PRIMARY KEY ❹ REFERENCES ❺ BillingDetails,
		  bankName varchar(255) NOT NULL,
		  swiftcode varchar(255) NOT NULL
		  );

❶

The table implementing the root class inherit.joined.v1.BillingDetails of the inheritance hierarchy will be referenced both by CreditCard and BankAccount datasets and thus requires a key to become addressable. Moreover the corresponding inherit.joined.v1.BillingDetails class requires this attribute to be the primary key anyway.

❷

Each CreditCard specific set of attributes belongs to exactly one BillingDetails instance and hence the id within our table CreditCard must be unique.

❸

As stated in ❷ each CreditCard dataset must refer to its parent BillingDetails instance.

❹ ❺

These constraints likewise describe ❷ and ❸ for BankAccount datasets.

The NOT NULL constraints implement their counterpart properties in the corresponding Java™ objects.

The mapping does not cover one important integrity constraint of our domain model: The base class inherit.joined.v1.BillingDetails is abstract. Thus each entry in the database must refer either to a inherit.joined.v1.CreditCard or a inherit.joined.v1.BankAccount instance. But the above database schema allows for datasets to appear in the BillingDetails table not being referenced by either BankAccount or CreditCard datasets.

So the current database schema actually refers to a domain model having a concrete base class BillingDetails.

exercise No. 23

Implementing figures by joined subclasses

Q:

Implement the model being given in Figure 945, “Figure subclasses” by joined subclasses.

A:

See inherit.joined.v2.Figure.

Prev  Up  Next
Joined subclasses  Home  Table per concrete class