Java Reference
In-Depth Information
<parameter property="postalCode" jdbcType="VARCHAR" />
<parameter property="country" jdbcType="VARCHAR" />
<parameter property="version" jdbcType="NUMBER" />
</parameterMap>
<insert id="insertWithExternalInfo"
parameterMap="fullParameterMapExample">
insert into account (
accountId,
username, password,
memberSince
firstName, lastName,
address1, address2,
city, state, postalCode,
country, version
) values (
?,?,?,?,?,?,?,?,?,?,?,?,?
)
</insert>
While that does not look any less verbose than the inline version, the difference
becomes more apparent when you start including additional statements. Not only
will they be simplified (because you do not need to specify the types for each
property), but the centralized maintenance also means that when you make
changes to the parameter map, you only have to do it once.
For example, everywhere that the
memberSince
property is passed in, it is auto-
matically handled as a
TIMESTAMP
database type. If later, we decide that
DATE
is
adequate (because we do not need to know the number of seconds since an
account was created), we do it in exactly one place—the parameter map.
Another added benefit to this approach is that the inline parameter map does
not need to be generated dynamically when first called.
In both of the previous examples, the code to call the statements is identical
(except for the name of the mapped statement in our example):
sqlMap.insert("Account.insertWithInlineInfo", account);
sqlMap.insert("Account.insertWithExternalInfo", account);
The difference between inline and explicit parameter maps is maintenance cost
and performance—both are improved by using externally defined parameter maps.
5.2.3
Autogenerated keys
With any database, the ability to uniquely identify a row in a table is absolutely crit-
ical. Nearly all databases include the means to automatically generate primary key
values for newly inserted rows. While this is convenient, it can be problematic
