String Phobia in Software Development

String phobia in software development is different from the medical condition of Linonophobia!

It is when teams or individuals do not use strings and want to replace every constant with enums.

Probably using enums is acceptable if they will not really change; for example “days of the week” but if they keep changing and the component has dependencies that are affected by this change then I see no point in using enums. This is very annoying in enterprise environments where a component has a number of dependencies and a change will affect multiple silos.

The clients on the other hand can convert these string to enums if they want to.

SOA Cook Book says:

Keep the types in the canonical schemas somewhat flexible and general, as they will potentially need to absorb a variety of service entity definitions. For example, it’s probably fine to use an enumeration in a service schema, but use a string to represent that same type in a canonical schema. It is surprising how little we can actually agree on. Maybe your USState enumeration has 50 items, but maybe the enum in the schema of the service you need to integrate with includes Guam and Puerto Rico.

Hibernate Filters

This is one way of writing a Hibernate filter. We have to define a filter first using @FilterDef as a global annotation, meaning that it can be applied anywhere in the code.

Then we apply the filter to where ever we want using @Filter and then we need to enable the filter in the session.

The reason for the filter is that when I do A.getstateTransitions() I want the list of B’s returned to be filtered.

@FilterDef(name=”myfilter”, defaultCondition=”TRANSITION_DATE > trunc (sysdate)”)

class A{

@OneToMany(…)
@Filter(name=”myfilter”)
private List<B> stateTransitions;

}

class B{

@NotNull
@Column (name=”TRANSITION_DATE”, columnDefinition=”DATE”)
private Calendar transitionDate;

}

Using:

org.hibernate.Session session = (Session) entityManager.getDelegate();
session.enableFilter(“myfilter”);
query.getResultList() // returns list of A’s where B.stateTransitions are after now.

Filters can have parameters but I didn’t need one here.

JPA Composite Primary Key

Here is an example of a composite primary key object for Hibernate/ JPA. It makes things more complicated by creating a relation from one of the pk fields to another entity. If we didn’t have this extra relation then the inner class would have another simple @Column instead.

@Entity
@Table(name="MY_TABLE" )
public class Test implements Serializable, Validatable
{
	public Test(){}

	@Id
	PK id;

        //other fields
	
	@Embeddable
	public static class PK implements Serializable{
		public PK (){}
		
		@Column (name="PK_1")
		private Long pk1;
		
		@ManyToOne(fetch=FetchType.EAGER,optional=false)
	    @JoinColumn(name="PK_2")
		private AnotherEntity ent;

		public boolean equals(Object obj) {
	        if (obj == this) return true;
	        if (obj == null) return false;
	        if (!(obj instanceof PK )) return false;
	        PK pk = (PK) obj;
	        if (pk.ent == null && pk.pk1 == null) return false;
	        return new EqualsBuilder().append(pk1, pk.pk1).append( ent, pk.ent).isEquals();
	    }

	    public int hashCode() {
	    	return new HashCodeBuilder().append(pk1).append(ent).toHashCode(); 
	    }	

		//getter/setter
	}

	//getter/setter

}