PartyId illustrates how to create an application managed primary key object for JDO Identity. Listed below is sample code and unit testing code for the PartyId object, which is described in section 4.6 of Enterprise Patterns & MDA.
org.eremite.corm.party.PartyId
The following code segment is our implementation of the PartyId object. We intend PartyId to serve as a primary key class for many objects in the corm-party distribution.
/**
* COMMERCIAL OBJECT RELATIONAL MAPPING (CORM) PROJECT
*
* This document is Copyright (C) 2004-2006 Alexander Saint Croix.
* All rights reserved.
*
* THE CONTENTS OF THIS FILE MAY BE USED UNDER THE TERMS OF THE
* ACADEMIC FREE LICENSE, VERSION 2.1.
*
* See http://opensource.org/licenses/afl-2.1.php for details.
*/
package org.eremite.corm.party;
import java.io.Serializable;
public class PartyId implements Serializable {
public String id = "";
public PartyId() {
}
public PartyId(String id) {
this.id = id;
}
public String getId() {
return id;
}
public void setId(String id) {
if (this.id.equals("")) {
this.id = id;
} else {
// do nothing.
}
}
public boolean equals(PartyId partyId) {
return partyId.id.equals(this.id);
}
public int hashCode () {
return this.id.hashCode();
}
public String toString () {
return this.id;
}
}
org.eremite.corm.party.PartyIdTest
In addition to those tests implemented below, the three following requirements are also defined by the JSR 243 specification:
The names of the non-static fields in the ObjectId class must include the names of the primary key fields in the JDO class, and the types of the corresponding fields must be identical.
The equals() and hashCode() methods of the ObjectId class must use the value(s) of all the fields corresponding to the primary key fields in the JDO class.
The equals() and hashCode() methods of the ObjectId class must use the value(s) of all the fields corresponding to the primary key fields in the JDO class.
The first two requirements define a relationship which must exist between the ObjectId and the JDO class which maps to it. As such, they intrude on your object model. For this reason, users are cautioned to evaluate other JDO Identity strategies.
The third requirement only applies if you're using an inner class for your primary key. Our example below is not an inner class. When we have an example of this functionality, we will include it here.
public void testPartyId() {
/**
* the ObjectId class must be public;
*
* the ObjectId class must have a public no-arg constructor,
* which might be the default constructor;
*/
PartyId party = new PartyId();
/**
* the ObjectId class must implement Serializable;
*/
Assert.assertTrue(party instanceof Serializable);
/**
* the field types of all non-static fields in the ObjectId
* class must be serializable, and for portability should be
* primitive, String, Date, Byte, Short, Integer, Long, Float,
* Double, BigDecimal, or BigInteger types. JDO
* implementations are required to support these types and
* might support other reference types;
*/
Assert.assertTrue(party.id instanceof Serializable);
Assert.assertTrue(party.id instanceof String);
/**
* all serializable non-static fields in the ObjectId class
* must be public;
*/
party.id = "hello";
/**
* the ObjectId class must override the toString() method
* defined in Object, and return a String that can be used
* as the parameter of a constructor;
*/
Assert.assertEquals(party.toString(), "hello");
/**
* the ObjectId class must provide a constructor taking
* either a String alone or a Class and String that returns
* an instance that compares equal to an instance that
* returned that String by the toString() method.
*/
Assert.assertTrue(new PartyId(party.toString()).equals(party));
}