Deleting Data

Now that we have covered data selects and updates, we can take a look at deletes. A delete is very similar to an update; just like an update, it takes a number of parameters and does not return any results. Let's start by implementing a delete(int) method in TestDao that deletes a row in the Test table identified by the primary key. In Listing 10-35, we modify the sqlMap Test.xml file and TestDao implementation.

Listing 10-35: sqlMap File for the Test Domain Object

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN" ¿ "http://www.ibatis.com/dtd/sql-map-2.dtd">   <sqlMap>     <!-- as previous -->          <delete  parameter>         delete from Test where TestId=#value#     </delete> </sqlMap>

The <delete> node declares a delete operation named deleteTest, which takes one parameter of type int that represents the primary key.

The addition to the DAO implementation class simply calls the delete method, passing it the name of the delete statement and the primary key value wrapped in a java.lang.Integer (as shown in Listing 10-36).

Listing 10-36: TestDao delete(int) iBATIS Implementation

import com.apress.prospring.ch12.domain.Test;      public class SqlMapClientTestDao      extends SqlMapClientDaoSupport      implements TestDao {          public void delete(int testId) {         getSqlMapClientTemplate().delete("deleteTest", new Integer(testId));     }          // other TestDao methods are implemented as stubs }

The Java code is very simple and does exactly what we expect it to do: it removes a row from the table identified by its primary key.

The same considerations about concern slush^[3] apply to the delete operations: a DAO implementation class should only delete rows that belong to its domain object. It is absolutely valid to use on delete cascade in your foreign key definitions, which effectively means that a delete of a master record propagates to the child rows, but do not delete the referenced records yourself.

^[3] Technically, this is just a same-layer concern slush. The real and nasty concern slush happens when a web layer contains parts of business logic, for example.