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 ❸:

package inherit.joined.v1;
	      public class RetrieveAll {
	      final Query searchBilling = session.createQuery("from inherit.tpc.v1.BillingDetails" ❶);
     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_,
              when is not null then 1 
              when is not null then 2 
              when is not null then 0 
              end as clazz_ 
              BillingDetails billingdet0_ left outer join
              BankAccount billingdet0_1_ on
	      left outer join
              CreditCard billingdet0_2_ on 

exercise No. 13

JPA constraints and database integrity.


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?


We take a look to the database schema:

CREATE TABLE BillingDetails (
		  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. 14

Implementing figures by joined subclasses


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


See inherit.joined.v2.Figure.