Shashi Velur’s blog

All the individual products in our organization use continuous integration development practice. However, all the products are built by different teams (with different skill-sets) under Sprints that do not share the same boundaries.

Some of these are complete products by themselves. They also are bundled together in a suite and so require integration testing. How do we apply continuous integration practice on a grand scale to this problem?

We ended up making these decisions:

1. The individual product team (with “inward” dependency) shall take the responsibilities of writing/maintaining the integration test cases.
2. We decided to push the individual product builds into this environment every week, mostly and also have the flexibility of being able to push the builds on demand, if necessary.
3. Start with a basic set of integration test cases and build upon them to keep it simple/Agile.
4. Start with manual steps to deploy these individual product builds into the integration environment and then slowly build a set of scripts to automate this.
5. Eventually, we should have a “push-button” integration environment where individual teams can push a button or set up rules to promote their builds in to this integration environment.
6. Decide that all teams should eventually move to a single source repository.
7. Initially, to keep it simple, all of the individual product teams will push only binaries into this environment.
8. We agreed upon a simple defect tracking process for reporting/escalating integration testing bugs.

Technorati Tags: Continuous Integration, Product Development

There are many real-world scenarios where Hibernate can be introduced on a legacy system that could be using straight JDBC for various reasons.

Also, there could be some pre-existing custom Java types to Database type mapping in the legacy application. Hibernate has it’s default mappings for each database excapsulated in the appropriate SQLDialect classes.

Fortunately, there is a very simple way to customize/override these SQL Types to Database types mappings by extending the SQLDialect class implementation corresponding to the Database in question.

The org.hibernate.dialect.SQLDialect abstract class has these following methods that are provided for overloading the SQL Types to Database types mapping. Also, there is a method to override the standard Database function name mappings:

• protected void registerColumnType(int code, int capacity, String name)
• protected void registerColumnType(int code, String name)
• protected void registerFunction(String name, SQLFunction function)

Here is an example of the usage of one of the above methods to override a mapping of a double (Java SQL type) to a “real” MS SQLServer type.

package com.x.y.common.dao;
import java.sql.Types;
import org.hibernate.dialect.SQLServerDialect;
public class MyMSSQLServerDialect extends SQLServerDialect {
  public MyMSSQLServerDialect() {
    super();
    //Override the default mappings for MS SQLServer
    registerColumnType( Types.DOUBLE, "real" );
  }
}

Also, there is a way to add custom value types in Hibernate by implementing either org.hibernate.UserType or org.hibernate.CompositeUserType.

Technorati Tags: custom Types mapping, Hibernate, Java SQL Types