Hi all,

Okay, I'm sick of typing out parameter map and result map stanzas, how
about you?  We'll always have them, as they are a primary structure
for an SQL map, and future tools may use them.  However, I want to
implement a shorthand method.  The approach would be similar to inline
parameter maps.  For example (excuse the % tokenization, it's just for
example purposes).

<select id="getPersonByID" parameterClass="int" resultClass="e.g.Person">
    SELECT 
        PERSON_ID   AS   %id%,
        FIRST_NAME AS   %firstName%,
        LAST_NAME  AS   %lastName%,
        BIRTH_DATE  AS   %birthDate,javaType=date,jdbcType=DATE%
     FROM PERSON
     WHERE PERSON_ID = #value#
</select>

Some caveats:

1) The SQL is less pure, and more mangled.  Although initially this
looks bad, I think most people use the built-in logging or P6Spy to
grab the real statements anyway.  Also, for initial SQL development,
it doesn't reduce the ability for a database admin to write the SQL
(or if it does in your case, you still have the option of an external
<resultMap>).

2) Dynamic SQL performance may be slightly impacted (no more so than
inline parameters, which is the only way to do dynamic SQL anyway).

3) The paramter tokenization may get out of hand.  We already know we
want a new syntax, and this will give us the additional motivation to
move in that direction.  Currently we have #parameters#,
$substitutions$ and with the above example of inline results, we'd
have %results%.

An option for different tokenization might be something like: 
P{parameter}, S{substitution} and R{result}.  This is similar to the
Ant ${property} syntax, and will have fewer conflicts with potential
new dynamic SQL languages (like velocity, which reservs #), and
certain databases (like JDE that often uses # in column names).

This would completely eliminate the need to write <resultMap>
elements.  Of course we'd need to forward some additional properties
like groupBy to the <select> element, and also include a facility for
the upcoming <subclass> element.  But neither of those pose a problem.
 This is mostly a change to the XML parser, and not to the
functionality of the framework.

Thoughts?

Cheers,
Clinton

Thoughts?

Reply via email to