I am much comfortable with Larry's idea.
On Sun, 16 Jan 2005 09:17:55 -0700, Clinton Begin <[EMAIL PROTECTED]> wrote: > 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 > > >
