I like it. As long as I can still do nested structures
<property name="stuffList" column="stuff" mapped-statement="getStuff" />
(probably wrong syntax, but you get the idea)
then I wouldn't have any problems with the shortcut. More intuituve anyway.
Jerry
On Sat, 15 Jan 2005 11:16:09 -0700, Clinton Begin
<[EMAIL PROTECTED]> wrote:
> 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?
>
