Unidirectional mandatory one-to-one: mandatory RI aspect.

[H Paul]

1. Basically, I want to understand the "Referential Integrity" aspect (like database RI) via Java code
2. I set up a Unidirectional mandatory one-to-one: Invoice---->BillOfLading
3. For "mandatory" aspect, I reenforce it at the constructor Invoice and set level setBillOfLading
4. For testing:

Invoice invoice=new Invoice(new BillOfLading());
Invoice invoice2=new Invoice(new BillOfLading());
invoice.setBillOfLading(invoice2.getBillOfLading());
Assert.assertEquals(invoice.getBillOfLading(), invoice2.getBillOfLading());

In this case 2 different invoices point to the same BillOfLading which is many-to-one.
Where do I miss the reenforcement for this case? OR Am I doing something wrong in the first place?

For reference:

public class Invoice {
	private BillOfLading billOfLading;

	public Invoice(BillOfLading billOfLading) {
		super();
	
		requiredCheck(billOfLading);
		this.billOfLading = billOfLading;
	}

	private void requiredCheck(BillOfLading billOfLading) {
		if (billOfLading==null)
			throw new IllegalArgumentException("BillOfLading required");
		
	}

	public BillOfLading getBillOfLading() {
		return billOfLading;
	}

	public void setBillOfLading(BillOfLading billOfLading) {
		requiredCheck(billOfLading);			
		this.billOfLading = billOfLading;
	}	
}


public class BillOfLading {	
	public BillOfLading() {
		super();
	}
}

[Steve Luke]

You will have to enforce that relationship yourself through code. You might change your requiredCheck method to something like this:

	private void requiredCheck(BillOfLading billOfLading) {
		if (billOfLading==null)
			throw new IllegalArgumentException("BillOfLading required");

		if (!billOfLading.checkAndAssignInvoice(this))
			throw new IllegalArgumentException("The assigned BillOfLading is assigned to another Invoice");
		
	}

Then write the checkAndAssignInvoice() method on billOfLading which keeps track of the Invoice objects which call the method, and makes sure only one ever does.

[H Paul]

1. I changed checkAndAssignInvoice to IsAlreadyAssigned so that I can see it from my end/head.

	private void requiredCheck(BillOfLading billOfLading) {
		if (billOfLading==null)
			throw new IllegalArgumentException("BillOfLading required");
		
		if (billOfLading.IsAlreadyAssigned(this)) {
	           throw new IllegalArgumentException("This BillOfLading is ALREADY assigned to another Invoice");  
		}
	}

2. The updated BillOfLading is below.

public class BillOfLading {	
	private Invoice invoice;
	
	public BillOfLading() {
		super();
	}

	boolean IsAlreadyAssigned(Invoice invoice) {
		if (this.invoice==null) {
			this.invoice=invoice;
			return false;
		} else
			return true;
	}
}

3. (Test passed.)

If I translated correctly what you have in mind, would it be OK that BillOfLading have a hidden reference to Invoice? (I do not what is the correct wording is.)

[Steve Luke]

That is what I would expect. One change I would make is to check if the Invoice being passed into IsAlreadyAssigned is the same one already assigned to this.invoice. If the passed in Invoice is the same as the stored Invoice then the One Invoice per BillOfLading relationship is maintained, and there is no need to fail the check.

[H Paul]

Is this what you're looking for? If I read what you said previously correctly.

	boolean IsAlreadyAssigned(Invoice invoice) {
		if (this.invoice==invoice)
			return false;      // This is the case where the same BillOfLading assigned again. OK
		else
			if (this.invoice==null) {  // This is to OK since first time.
				this.invoice=invoice;
				return false;
		} else
				return true;  // This is the case where different BillOfLading assigned again. NOT OK.
	}
	
	
	
	Code for Test:
	
	
		Invoice invoice=new Invoice(new BillOfLading());
		Invoice invoice2=new Invoice(new BillOfLading());
		invoice.setBillOfLading(invoice.getBillOfLading());   // This should be OK
		invoice.setBillOfLading(invoice2.getBillOfLading());   // This should NOT be OK (exception expected)

[H Paul]

1. Thanks Steve.

2. Is there any code template (or standard) to handle RI via Java?
OR it comes with experience on handling these RI?


3. Just a side note:

For JAXB and for JPA, I added 2 annotation

public class BillOfLading {		
	@Transient	 		// for JPA:  should not be persisted
	@XmlTransient    		// for JAXB: avoid circular reference exception
	private Invoice invoice;

}

[H Paul]

Steve,

Just a side note again, when I put these 2 to have a UML class diagram, a bi-directional from BillOfLading to Invoice is
show up. This is unexpected side effect.

For a good laugh: If such thing like @UMLTransient so that I can put on

public class BillOfLading {        
    @Transient          // for JPA:  should not be persisted   
    @XmlTransient           // for JAXB: avoid circular reference exception   
    
    @UMLTransient       // Not to show internal RI from BillOfLading to Invoice
    private Invoice invoice;   
  
}