The question is about the best practice usage for RowMapper in master/detail scenarios where we want to eagerly fetch details using spring jdbc.
Assume that we have both Invoice and InvoiceLine classes.
public class Invoice{
private BigDecimal invId;
private Date invDate;
private List<InvoiceLine> lines;
}
public class InvoiceLine{
private int order;
private BigDecimal price;
private BigDecimal quantity;
}
When using Spring Jdbc with a row mapper we usually have a
public class InvoiceMapper implements RowMapper<Invoice>{
public Invoice mapRow(ResultSet rs, int rowNum) throws SQLException {
Invoice invoice = new Invoice();
invoice.setInvId(rs.getBigDecimal("INVID"));
invoice.setInvDate(rs.getDate("INVDATE"));
return invoice;
}
}
Now the problem is I want to eagerly fetch InvoiceLine's related with this invoice instance.
Would it be OK if I query database in the rowmapper class? Or anyone prefers another way? I use the pattern below but not happy with that.
public class InvoiceMapper implements RowMapper<Invoice>{
private JdbcTemplate jdbcTemplate;
private static final String SQLINVLINE=
"SELECT * FROM INVOICELINES WHERE INVID = ?";
public Invoice mapRow(ResultSet rs, int rowNum) throws SQLException {
Invoice invoice = new Invoice();
invoice.setInvId(rs.getBigDecimal("INVID"));
invoice.setInvDate(rs.getDate("INVDATE"));
invoice.setLines(jdbcTemplate.query(SQLINVLINE,
new Object[]{invoice.getInvId},new InvLineMapper());
return invoice;
}
}
I sense that something is wrong with this approach but could not get a better way. I would be more than glad if someone can show me why is this a bad design and if so what would be the correct usage.
The ResultSetExtractor is a better option for doing this. Execute one query that joins both the tables and then iterate through the result set. You will need to have some logic to aggregate multiple rows belonging to the same invoice - either by ordering by invoice id and checking when the id changes or using a map like shown in the example below.
jdbcTemplate.query("SELECT * FROM INVOICE inv JOIN INVOICE_LINE line " +
+ " on inv.id = line.invoice_id", new ResultSetExtractor<List<Invoice>>() {
public List<Invoice> extractData(ResultSet rs) {
Map<Integer,Invoice> invoices = new HashMap<Integer,Invoice>();
while(rs.hasNext()) {
rs.next();
Integer invoiceId = rs.getInt("inv.id");
Invoice invoice = invoces.get(invoiceId);
if (invoice == null) {
invoice = invoiceRowMapper.mapRow(rs);
invoices.put(invoiceId,invoice);
}
InvoiceItem item = invLineMapper.mapRow(rs);
invoice.addItem(item);
}
return invoices.values();
}
});
What you have recreated here the 1 + n
problem.
To solve it you need to use change your outer query to a join and then hand craft a loop to parse the flat join result set into your Invoice 1 -> * InvLine
List<Invoice> results = new ArrayList<>();
jdbcTemplate.query("SELECT * FROM INVOICE inv JOIN INVOICE_LINE line on inv.id = line.invoice_id", null,
new RowCallbackHandler() {
private Invoice current = null;
private InvoiceMapper invoiceMapper ;
private InvLineMapper lineMapper ;
public void processRow(ResultSet rs) {
if ( current == null || rs.getInt("inv.id") != current.getId() ){
current = invoiceMapper.mapRow(rs, 0); // assumes rownum not important
results.add(current);
}
current.addInvoiceLine( lineMapper.mapRow(rs, 0) );
}
}
I obviously haven't compiled this ... hopefully you get the idea. There is another option, use hibernate or any JPA implementation for that matter, they do this sort of thing out of the box and will save you a bunch of time.
Correction: Should really use the ResultSetExtractor
as @gkamal has used in his answer, but the over all logic still stands.
I don't like using the ResultSetExtractor
because it processes the entire ResultSet and returns one (possibily huge) object.
With my solution you get one object per group of related rows and you can process this object before you get the next one: in my application I created a CollectingRowMapper
interface and an abstract implementation. See code below, it contains Javadoc comments.
CollectingRowMapper interface:
import org.springframework.jdbc.core.RowMapper;
/**
* A RowMapper that collects data from more than one row to generate one result object.
* This means that, unlike normal RowMapper, a CollectingRowMapper will call
* <code>next()</code> on the given ResultSet until it finds a row that is not related
* to previous ones. Rows must be sorted so that related rows are adjacent.
* Tipically the T object will contain some single-value property (an id common
* to all collected rows) and a Collection property.
* <p/>
* NOTE. Implementations will be stateful (to save the result of the last call
* to <code>ResultSet.next()</code>), so <b>they cannot have singleton scope</b>.
*
* @see AbstractCollectingRowMapper
*
* @author Pino Navato
**/
public interface CollectingRowMapper<T> extends RowMapper<T> {
/**
* Returns the same result of the last call to <code>ResultSet.next()</code> made by <code>RowMapper.mapRow(ResultSet, int)</code>.
* If <code>next()</code> has not been called yet, the result is meaningless.
**/
public boolean hasNext();
}
Abstract Implementation class:
import java.sql.ResultSet;
import java.sql.SQLException;
/**
* Basic implementation of {@link CollectingRowMapper}.
*
* @author Pino Navato
**/
public abstract class AbstractCollectingRowMapper<T> implements CollectingRowMapper<T> {
private boolean lastNextResult;
@Override
public T mapRow(ResultSet rs, int rowNum) throws SQLException {
T result = mapRow(rs, null, rowNum);
while (nextRow(rs) && isRelated(rs, result)) {
result = mapRow(rs, result, ++rowNum);
}
return result;
}
/**
* Collects the current row into the given partial result.
* On the first call partialResult will be null, so this method must create
* an instance of T and map the row on it, on subsequent calls this method updates
* the previous partial result with data from the new row.
*
* @return The newly created (on the first call) or modified (on subsequent calls) partialResult.
**/
protected abstract T mapRow(ResultSet rs, T partialResult, int rowNum) throws SQLException;
/**
* Analyzes the current row to decide if it is related to previous ones.
* Tipically it will compare some id on the current row with the one stored in the partialResult.
**/
protected abstract boolean isRelated(ResultSet rs, T partialResult) throws SQLException;
@Override
public boolean hasNext() {
return lastNextResult;
}
protected boolean nextRow(ResultSet rs) throws SQLException {
lastNextResult = rs.next();
return lastNextResult;
}
}
I use this code with Spring Batch too, in a custom subclass of JdbcCursorItemReader
: I described this solution in another answer.