On Sat, 15 Jan 2005 11:16:09 -0700, Clinton Begin
<[EMAIL PROTECTED]> wrote:
> Okay, I'm sick of typing out parameter map and result map stanzas, how
Would it be feasible to have a result map for just the unusual stuff?
> <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>
The only thing that is exceptional there is the birthDate field..other
than that, the default result map would be just fine.
I hate the idea of messing with the SQL. IMO, one of the reasons
people like SQL Maps is that the query language is untouched by the
framework. What I put in is what I get out (with the explicit
exception of dynamic SQL).
So, instead of mangling the SQL, maybe we could provide a way to keep
the SQL clean, and alter the result map instead. That way, instead of
needing a full result map, you would only need to explicity map the
exceptions.
In terms of the work involved for users, the impact is minimal - the
existing method will continue to work, and in the cases where all you
need is one property mapped differently, it is 3 lines in your xml
file.
...and we get the added benefit of knowing the that SQL remains "pure".
> 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>).
Hmm, another idea. How about this:
<select id="getPersonByID" parameterClass="int" resultClass="e.g.Person">
<result property="birthDate" column="BIRTH_DATE" javaType="date"
jdbcType="DATE" />
SELECT
PERSON_ID AS id,
FIRST_NAME AS firstName,
LAST_NAME AS lastName,
BIRTH_DATE AS birthDate
FROM PERSON
WHERE PERSON_ID = #value#
</select>
That might even work for tweaking your parameter mapping. :-)
> 2) Dynamic SQL performance may be slightly impacted (no more so than
> inline parameters, which is the only way to do dynamic SQL anyway).
Not sure how either of these approaches would impact that...
> 3) The paramter tokenization may get out of hand. We already know we
I agree and think that avoiding that is important. Simpler is better.
Oh, and I also agree that collections suck, but I still like Vic in
spite of them. ;-)
Larry
