Scala – Implicit Class

Ok so this isn’t a deep dive into implicit’s in scala but rather a reminder on how helpful they can be. The camp on using implicit in scala is divided as you can use them in several different ways and like everyone you’ll go crazy and use them everywhere, then you’ll stop.

Anyway implicit classes are an ideal way to add functionality to an existing type, huh? Ok so I get fed up of seeing this

val time = LocalTime.now()
val someSpecialTime = SomeSpecialTime(time)

The code to me doesn’t read naturally anymore after using scala and I’d prefer time.toSomeSpecialTime, well there is a way if you use an implicit class:

object Converters {
  implicit class LocalTimeToSpecialTime(val localTime: LocalDateTime) extends AnyVal {
    def toSomeSpecialTime = SomeSpecialTime(time)
    def doSomthingElse = AnotherSpecialTime(time)
  }
}

Now I can import the class and use it as I want.

The implicit class however can not be top level and MUST be defined in a scope where method calls are allowed -> package, class, object. I tend to wrap them inside an object.

I like to use them as a kind of factory, where a string is passed in and the correct type is returned.

def toSurfaceExtrapMethod: SurfExtrapolationMethod = {
  value match {
    case "SE_NONE" => SurfExtrapolationMethod.NONE()
    case SE_FLATLINE" => SurfExtrapolationMethod.FLATLINE()
    case "SE_FLATLINE_TO_ZERO" => SurfExtrapolationMethod.FLATLINE_TO_ZERO()
    case "SE_WITHIN_TOLERANCE" => SurfExtrapolationMethod.WITHIN_TOLERANCE()
    case "SE_STEP_UP_WITHIN_TOLERANCE" => SurfExtrapolationMethod.STEP_UP_WITHIN_TOLERANCE()
  }
}

Also it’s possible to pass in values so you can have something like

def toRangeType(fixedRange: Option[FixedRange] = None): RangeType = {
  value match {
    case "FIT_BOTH" => RangeType.FitBoth()
    case "FIT_END" => RangeType.FitEnd()
    case "FIXED" => RangeType.Fixed(fixedRange.get)
    case "MIN_START" => RangeType.MinStart()
  }

So you can do something like

val rangeType = "FIXED".toRangeType(Some(FixedRange.FALSE))
Advertisements

Folding observables with Scala

I had a bunch of observables that I wanted to merge into a single observable and then subscribe to it. I knew that I could use merge but had an unknown sequence size of observables, so how could I do it? Easy I can use the merge and fold functions:-

val obs1: Observable[Int] = Observable.from(Seq(1,2,3,4,5))
val obs2: Observable[Int] = Observable.from(Seq(6,7,8,8,10))
val obs3: Observable[Int] = Observable.from(Seq(11,12,13,14))

val totalObservable = Seq(obs1, obs2, obs3)
  .fold(Observable.just[Int]())((a,b) => a.merge(b))

totalObservable.foreach(x => println(s"This is the value ${x}"))

The fold takes in an initial value, in this case “Observable.just[Int]()” followed by the aggregation function “a.merge(b)”. It took me about 30 mins to figure out the syntax, especially around the initial value but the code is clean and clear.

Hibernate and sets – use at your peril

For the past 3 weeks I’ve spent hours tuning the performance in one of the applications we use. Unfortunately rather than spend some time and come up with a proper reporting solution I was tasked to fix the existing solution which is to report off our live transactional system. We use EJB3 on JBoss so hibernate it is, which I personally think is an excellent framework for getting your application up and running quickly. Hibernate have always stated that performance isn’t it’s goal so I can’t blame hibernate for anything I’ve found. I tackled the problem in the usual way, add some sql logging and see what’s really happening and look for the usual suspects, lazy loading, code structure etc. Where I saw collections being loaded up separately I added Join fetches and rerun the reports. This worked really well then I noticed that no matter how I wrote the JPQL it always seemed to be running seperate queries for some of the realtionships. That’s when the bulb flashed they were defined as Sets!!

An example of such a thing:

@OneToMany(mappedBy="transaction")
private Set taxComponents = new HashSet(1);

I understand why sets are used but as I’m in control of what gets put in I can safely use:

@OneToMany(mappedBy="transaction")
 private Collection taxComponents = new ArrayList(1);
 

So using set’s is great but it comes at a cost and beware it’s not just fetches but deletes and inserts have a similar issue in that they get deleted one by one and then reinserted to ensure uniqueness, so if you do update the set it also has a performance hit.

The performance of the major report moved from 30 mins to 6 mins, still not lightning fast but a good improvement. I could of course move to native SQL but I didn’t want to have to rewrite a load of code to do that.

EJB 3.0 Injecting The Correct Implementation

When using stateless and stateful session beans I often find that I’m creating one interface per one implementation, which will be enhanced with the release of the 3.1 spec and implicit interfaces. Anyway on one of the occasions I had actually had multiple implementations of an interface that I wanted to inject, this made me stop and think how do I that!! It turns out it was pretty simple with a few annotations.

On your class that is implementing the interface you need to use the name attribute: –


@Stateful(name="xxx.AssetTypeOverrideService")
public class AssetTypeOverrideService implements OverrideService{

@Stateful(name="xxxRuleTypeOverrideService")
public class RuleTypeOverrideService implements OverrideService {

Then on the bean you want inject these into you use:


@EJB(beanName="xxx.AssetTypeOverrideService")
private OverrideService assetOverrideService;
	
@EJB(beanName="xxx.RuleTypeOverrideService")
private OverrideService ruleTypeOverrideService;

The name can be anything you want I just think it’s logical to keep it the same as the class and the beanName obviously is the same value of the bean you want to inject that has the correct implementation.

It seems easy now but it did make me stop and think.

EJB 3.0 Interceptors

I wanted to carry out some processing when an entity was committed to the db, I could of used the lifecycle annotation @PostPersist in the bean itself but that that would go against leaky abstraction (see post Non-anaemic models). Anywho it was pretty simple to get this working all that I had to use were a couple of annotations.

The first @EntityListerners which accepts an array of classes that will become your event handlers:

@EntityListeners(ErrorListener.class)
public class SystemError implements Serializable {

The next is to annotate the methods in your listener class that will handle the various events. The annotations that can be used are:

    @PrePersist Executed before the entity manager persist operation is actually executed or cascaded. This call is synchronous with the persist operation.
    @PreRemove Executed before the entity manager remove operation is actually executed or cascaded. This call is synchronous with the remove operation.
    @PostPersist Executed after the entity manager persist operation is actually executed or cascaded. This call is invoked after the database INSERT is executed.
    @PostRemove Executed after the entity manager remove operation is actually executed or cascaded. This call is synchronous with the remove operation.
    @PreUpdate Executed before the database UPDATE operation.
    @PostUpdate Executed after the database UPDATE operation.
    @PostLoad Eexecuted after an entity has been loaded into the current persistence context or an entity has been refreshed.

Note that if you are using EJB dependency injection it won’t work in your listener as it’s not managed by your container buy you can use jndi: –

Context ctx = new InitialContext();
XXXService service = (XXXService) ctx.lookup("EARNAME/XXXServiceBean/local");

Joda with JPA

I have to work with a few legacy databases that are used by several different apps (apparently the database is a perfect integration point), and I want to use the Joda api in my persistence. In this example the date is actually stored as a string, genius! I’m going to use LocalDate as the string doesn’t store the time element. If you are lucky enough and the database is actually storing date time check this post out Joda With DateTime

To start with a create a simple helper class that converts String to LocalDate and LocatDate to String

public static LocalDate createLocalDateForString(String dateString){
  DateTimeFormatter fmt = DateTimeFormat.forPattern("yyyyMMdd");
  return StringUtils.isEmpty(value) ? null :  fmt.parseDateTime(dateString).toLocalDate();	
}
    
    public static String createStringForLocalDate(LocalDate date){
    	return date.toString("yyyyMMdd"); 
    }

Next is to create your own user type. This is done by implementing org.hibernate.usertype.UserType. The main methods I’m implement are

public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
			throws HibernateException, SQLException {
		LocalDate result = null;
		String dateAsString = rs.getString(names[0]);
		if(!rs.wasNull()){
			result = StringUtils.isNotEmpty(dateAsString) ? DateHelper.createLocalDateForString(dateAsString) : null;
		}
		return result;
	}

public void nullSafeSet(PreparedStatement statement, Object value, int index)
			throws HibernateException, SQLException {
		if(value == null){
			statement.setNull(index, SQL_TYPES[0]);
		}else{
			String dateAsString = DateHelper.createStringForLocalDate((LocalDate)value);
			statement.setString(index, dateAsString);
		}
}

All that is left is to add the annotation to each of your entity properties that you want to use as LocalDate.

@org.hibernate.annotations.Type(type = "xxx.LocalDateUserType")

Using Hibernate Search in SEAM 2.0 Application

I implemented hibernate search recently in a SEAM project I was working on. I wanted to use the excellent suggestion tag from the excedel library and I wanted to use an index rather than hitting the database for each of the searches. I also wanted to use wildcard searches and for each keystroke this would be far to expensive. To implement it I completed the following steps: –

In my persistence.xml I added the following to the properties of my persistence-unit:-

<property name="hibernate.search.default.indexBase" value="PATH TO YOUR INDEX DIRECTORY"/>
<property name="hibernate.ejb.post-insert" value="org.hibernate.search.event.FullTextIndexEventListener"/>
<property name="hibernate.ejb.post-update" value="org.hibernate.search.event.FullTextIndexEventListener"/>
<property name="hibernate.ejb.post-delete" value="org.hibernate.search.event.FullTextIndexEventListener"/>

The path of your index base can be anywhere you want as long as the application has permission to write to it.

To used hibernate search you need to identify and highlight all of the classes that you want to search, you also need to identify each of the properties that you want indexed and the indexing strategy, you can find out what the various types are here Hibernate Search

@Indexed(index="index_direcory")
public class SomeClass

@Field(index=Index.TOKENIZED, analyzer = @Analyzer(impl = LowerCaseAnalyser.class))
@Column(name = "inv_name", length = 200, nullable = true)
private String name;

Inject an instance of FullTextEntityManager into your code. I used a stateless session bean that was used throughout the application

@In
private FullTextEntityManger entityManager;

I used a three different query types, RegEx, Prefix and WildCard.

RegexQuery(new Term(fieldName,".*[^-'\\w]" + searchString.toLowerCase() + "(\\s|$)"));
PrefixQuery(new Term(fieldName,searchString.toLowerCase()));
WildcardQuery(new Term(fieldName,'*'+searchString.toLowerCase()+'*'));

The regex one was used to search for firstname surname i.e. Jo Bloggs. The prefix query was used to search for Jo* i.e. Joanne, Jo Bloggs. The wildcard one, the most expensive one, was used to search for *Jo* i.e. Jones, BillyJoBloggs. The fieldname is the obviously the name of the field, so in:-

@Field(index=Index.TOKENIZED, analyzer = @Analyzer(impl = LowerCaseAnalyser.class))
private String name;  

FiledName would = name

All that is left to do it actually query the index and this is done by:

entityManager.createFullTextQuery(query,SomeClass.class).getResultList();

This has been in production for a some time now and it’s been stable and performed well. There has only been one instance to date of the index getting screwed up but I catered for that and enable the index to be rebuilt. I also had to provide this as any update to the indexed fields via direct sql wouldn’t be updated.