No rush. I just don't want to lose track of them.
Clinton
On Mon, Sep 7, 2009 at 11:11 AM, wrote:
> Sorry, I was just waiting for more feedback about the desirability of
> the prefix and property/field changes and I thought that you've filed
> a ticket for the other one. I can't create them just
Sorry, I was just waiting for more feedback about the desirability of
the prefix and property/field changes and I thought that you've filed
a ticket for the other one. I can't create them just right so I'll
do it tonight GMT-3 :).
Best regards
--
Carlos
On Mon, Sep 07, 2009 at 08:28:25AM -0600, C
Carlos, are you going to create JIRA tickets for your 3 suggestions? (this
prefix one, the property/field order, and the unconstrained mapper methods)
If it isn't in JIRA, it doesn't have a hope of getting done. :-)
Clinton
On Wed, Sep 2, 2009 at 9:20 AM, Clinton Begin wrote:
> Your posts are
Your posts are well researched and since they're more like proposals,
it's probably a good idea to submit a Jira ticket for each of them.
Cheers,
Clinton
On 2009-09-01, Carlos Pita wrote:
>> If I'm right, both alternatives are easily implementable: giving prefix
>> at use-place or giving it at d
> If I'm right, both alternatives are easily implementable: giving prefix
> at use-place or giving it at definition-place. I tend to prefer the
> first one.
Sorry, I confused use-place with mappedStatement. Actually, the use-place in
Iawo's proposal was a nested resultMap. There is no "global" pre
After a closer examination at the implementation of DefaultResultSetHandler
even the original proposal by Iwao doesn't look that hard to get working.
The sequence of execution is as follows:
handleResultSets(mappedStatement)
handleResults
loadResultObject <-+
Hi all,
I would like to revive this old thread, which is representative of a few
other ones that can be found in the list with some effort. I understand
both the original proposal and the difficulty that Jeff pointed out.
But I think a very simple solution can be implemented if instead of
"paramet
I understand the issue, and your proposed solution. I think the
implementation could get complex - especially if the referenced result map
referenced other result maps. Result processing is already pretty complex
in iBATIS - this would add to that complexity.
I'd like to hear from other users t
Hi all,
It was a great news that [#IBATIS-225] had been implemented.
I'm wondering if it can be improved a little bit more.
--
Assuming I have 2 simple java classes.
Needless to say, there are corresponding tables in a database.
public class Staff {
Integer id;
String name;
// ... ac
