Keep in mind that I'm not suggesting we ever do away with result maps entirely. I would just like a shorthand way to manage it.
That said, I agree with your assertions, and I like some of your suggestions. Let's keep the conversation open. I'd like to hear what some of our users think. Clinton On Sun, 16 Jan 2005 06:42:09 -0700, Larry Meadors <[EMAIL PROTECTED]> wrote: > 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 >
