+1 for changing the silentlyFailWhenNoResultClassOrResultMapPresent behaviour, I have to admit I stumpled
across this problem for several times ;-)
--- Original Nachricht ---
Absender: Larry Meadors
Datum: 16.08.2008 07:42
Amen!
? = ambiguous
One more thing: What about a
shootFlamesOutTheBackOfTheComputerWhenNoResultClassOrResultMapPresent
setting somewhere to offset the
silentlyFailWhenNoResultClassOrResultMapPresent default. ;-)
Maybe even have a default result mapping option - if all else fails,
just dump the results into a map (and watch Vic clap with glee). :-D
Larry
On Fri, Aug 15, 2008 at 11:34 PM, Clinton Begin <[EMAIL PROTECTED]> wrote:
One thing I forgot to mention...
With iB3 I don't think we should support question mark parameters at all
anymore. So even if you specify the <param> elements, they're no longer
ordinal. They are looked up from the #param placeholders in the statement.
That way SQL is more readable, and even the <param> elements need not be
repeated if used.
Clinton
On Fri, Aug 15, 2008 at 10:57 PM, Larry Meadors <[EMAIL PROTECTED]>
wrote:
On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <[EMAIL PROTECTED]>
wrote:
> 3. <param element> : The thought here is to allow for specifying the
> options (e.g. javaType="") outside of the SQL statement and to avoid
> duplication if the same property is used more than once. But maybe it's
> too
> much for such a rare case? But still, some people may prefer to keep
> the
> param details out of the SQL itself. Hmmm... anyone else have an
> opinion
> here? I'd love to only use inline params myself. But it's almost too
> easy
> to agree in this case. :-)
I like the *option* for param elements because it can help keep the sql
cleaner.
One of the biggest advantages of ibatis is that you can easily take
the sql and just run it. IMO, adding a ton of inline parameter mapping
info can make that harder.
Larry
