Kevin Gaffney’s Software Development Blog

Since my last update where I discussed an implementation of free form search, I now have this requirement fufilled with a few caveats.

The current implementation is a free from search which is implemented for all but two of Dermot’s requirements (see previous post).

That is for example you can type a policy number or a client name etc into the one search box and without specifying further options on type it will pull back the pertinent client results.

It is a free from search for Dermot’s search specification only.

I have implemented this in the following fashion:

The retreiveClientsRequestHandler bean which handles requests for client search has a list of query fields

    <bean id=“retrieveAllCustomersRequestHandler” class=“com.zeninvent.dmib.web.handler.retrieveAllCustomersRequestHandler”>

            <property name=“climasListProxyDAO”><ref bean=“climasListProxyDAO”/></property>

            <property name=“queryFields”>

              <list>

                     <!– Any  value here must be specifed its table implmentation list in the climasListProxyDAO –>

                     <value>taxStatus</value>

                     <value>surname</value>

                     <value>phone1</value>

                     <value>address1</value>

                     <value>address2</value>

                     <value>occupationS</value>

                     <value>employerS</value>

                     <value>policyNum</value>

                     <value>maritalStatus</value>

              </list>

            </property>

    </bean>

Any field\column which is signed up for search must first be entered here.

Then the clientMasterListProxy bean has a list of columns for each table to be queried.

    <bean id=“climasListProxyDAO” class=“com.zeninvent.dmib.db.hibernate.HibernateClimasListProxyDAO”>

        <property name=“sessionFactory”><ref bean=“sessionFactory”/></property>

        <property name=“ftrenqFields”>

              <list>

                     <value>occupationS</value>

                     <value>employerS</value>

              </list>

        </property>

        <property name=“policyFields”>

              <list>

                     <value>policyNum</value>

              </list>

        </property>

        <property name=“climasFields”>

              <list>

                           <value>taxStatus</value>

                     <value>surname</value>

                     <value>phone1</value>

                     <value>address1</value>

                     <value>address2</value>

                     <value>maritalStatus</value>

              </list>

        </property>

While this list currently corresponds only to match the values in the original list in the handler it may be nice in time to have some redundancy here where the search list in the requestHandler may not utilise all of the options in the lists for performance reasons etc.

Then in the ClientMasterListProxyDAO it is simply a case of iterating through the lists and adding the appropriate  criteria to the right Criteria objects.

Example:     

// builds a list for the ftrenqFiels set in the servlet context these must match fields in the ftrenq table

                     if(ftrenqFields.contains(queryCriteria.get(i).getPropertyName())){

                           log.debug(“Non climas value being added to query:”+queryCriteria.get(i).getPropertyName());

                           critFtrenq.add((Criterion) queryCriteria.get(i).getQueryCriterion());

                           isAdded = true;

                     }

Once the criteria list is then built we return the results to the calling requestHandler which places the results back into the model.

While one can argue that there are could be performance issues against checking for example a telephone number against all the search list options in our live database with two and a half thousand customers there are no such issues.

If performance issues were to arise in the future or the days were suddenly to get longer I would consider implementing some regular expression pattern matching on the query field to narrow the list of possible search fields.

That took me until late Saturday afternoon to implement after which I spent the rest of the evening knocking off requirements :

CM09(Mapping) & CM11(For quotation – re-using David’s already developed quotation & front end purchase component).

Today I focused on CM06 the customer contact log.

While reading more about relationship mapping in hibernate there is an improved implementation for mapping, which up to now we have not been using, through annotations. Today that changed.

The beauty about using hibernate annotations is that they provide a further abstraction away from the database and also remove the need for the rather awakard mapping.hbm.xml file.

The other added advantage is if we do need to recfactor the table itself, for example adding a column, under the old regieme it would require updating the mapping.hbm.xml and then updating the POJO. However, now we just add the field to the POJO and hey presto!

The hibernate annotations are placed in the POJO

Example:

@Entity

@Table(name = “climas”)

@Proxy(lazy=false)

public class Climas implements java.io.Serializable{

       @Id

       @GeneratedValue(strategy = GenerationType.AUTO)

       @Column(name=“clientKey”)

       private int clientKey;

       @OneToOne

       @PrimaryKeyJoinColumn

       private Ftrenq ftrenq;

       @OneToMany(fetch=FetchType.EAGER)

       @JoinColumn(name=“clientKey”)

       private Set<ContactLog> contactLog ;

}

Most of the above annotations are self explanatory.

@Proxy is the fix for the hibernate org.hibernate.LazyInitializationException which translates to:

“Indicates access to unfetched data outside of a session context. For example, when an uninitialized proxy or collection is accessed after the session was closed” 

A way to fix this is to write a sessionIntercoter which has a similar theme to our transaction interceptor from a previous post.

I’ll do this if I get time near the end of the project.

However, we need to hydrate  the Climas pojo with a contactLog Set eagerly which is hibernates default to avoid another dreaded null pointer!

The @OneToMany @OneToOne do as they say on the tin.

Now because our mappings are being phased out I have had to re-factor the ftrenq table column names to a nicer format as before the xml mapping swept the column names under the carpet.

The ftrenq’s tables has 156 columns which required manual renaming. I could have used the @Column annotation to override the defaults in the Ftrenq POJO but I felt the column renaming was quicker.

This change in moving away from hibernate mappings to annotations also requires a change in our servlet sessionFactory where we now have an annotated classes list as well. The nice thing about it is we can use mappings and annotations side by side so there doesn’t have to be a complete re-factoring of every POJO and table but more a gentle migration as we code new tables and POJO’s with annotations and re-factoring old POJOs as required like the case today.

I also made the bold decision to truncate all DATETIME types in the migrated data to DATE to remove the absurdity of know the exact second of when a client signed for a policy. Don’t worry all the times were 00:00:00 anyway! J

The Client POJO has also now been officially deprecated and we hope to remove it completely in time.

David has the purchase of mortgage protection nicely tied up. And has been liaising with Dermot over a couple of options regarding the quotation service and purchase options.

anon…

HD16 Tomorrow agenda here:

http://gaffneykev.no-ip.info/ca400blog/Docs/Meeting%20HD16%20Agenda.doc

Screenshot of the contact log UI:

http://gaffneykev.no-ip.info/ca400blog/Docs/contactlOG.JPG