I have a resultMap
and a select
SELECT column1,column2 FROM TESTBEAN
when I execute my java testcase, the error occurs:
--- The error occurred while applying a result map.
--- Check the ConsumableUnit.consumableUnitMap.
--- Ch
FWIW: You guys probably already thought of this, but you can short circuit
this by using a field naming convention different from the property naming
convention... like "_field"
Clinton
On Sun, Sep 6, 2009 at 10:36 AM, Brandon Goodin wrote:
> Forget the JavaBean spec and provide column to metho
Forget the JavaBean spec and provide column to method mapping :) Then you
could intentionally map a column to a "set" method on a class if you wanted.
Of course you may open a can of worms with that since some people may want
to pass multiple columns to a method. But, then again, that's not much
di
I'm all for field access! Or a default field-then-property. I'm also
fond of the syntax prop.(field) that you came out with time before in
the list, but again reversing the default (prop).field.
Best regards
--
Carlos
On Sun, Sep 06, 2009 at 01:23:18AM -0600, Clinton Begin wrote:
> I'm almost sa
I wouldn't mind if this was a configurable resolution order.
-Ken
On Sep 6, 2009, at 12:23 AM, Clinton Begin
wrote:
I'm almost sad that I ever supported JavaBeans properties... fields
would have been so much better. I wonder if it's too late to make
that call...
Does anyone actually
Thanks a lot Clinton,
I tried to replace with but it didn't do the trick. Here's a
JIRA ticket with test case attached
https://issues.apache.org/jira/browse/IBATIS-646.
Olaf
Clinton Begin wrote:
>
> Can you create a failing unit test and attach it to a JIRA ticket?
>
> For giggles, make al
Can you create a failing unit test and attach it to a JIRA ticket?
For giggles, make all of the "bidResult" properties instead of
...
Clinton
On Sat, Sep 5, 2009 at 4:43 PM, olafos wrote:
>
> Hi I was using IBatis 2 and decided to try out IBatis 3 beta 3. I have a
> problem with association m
I'm almost sad that I ever supported JavaBeans properties... fields would
have been so much better. I wonder if it's too late to make that call...
Does anyone actually care if iBATIS uses getter/setters instead of fields
directly?
The only case I can think of is for "calculate on set" type logi
I'm not quite sure about your question...
* What are you referring to when you say "the custom cache" -- I'm
assuming that's something you've implemented.
* How are you hooking it into your statements?
* Can you provide a simple unit test to demonstrate the behavior (e.g. you
could just us
