Hi Gilles, Yes that's correct. However, the goals of each are the same. The "extends" functionality was created to reduce the amount of XML code required to define parameter and result maps. With inline parameters, not only is the XML reduced, it's eliminated altogether. It's basically "less XML" vs. "no XML". So there would be no need to extend either.
Cheers, Clinton On Sat, 15 Jan 2005 19:20:18 +0100, Gilles Bayon <[EMAIL PROTECTED]> wrote: > Just a fast remark, > With this system you cannot extends > resultMap or parameterMap :-( > > -----Message d'origine----- > De : Clinton Begin [mailto:[EMAIL PROTECTED] > Envoyé : samedi 15 janvier 2005 19:16 > À : ibatis-dev@incubator.apache.org > Objet : Inline Result Maps. > > 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? > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14/01/2005 > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14/01/2005 > >
