Here is one guy's opinion: It isn't an issue for a few reasons.
First, it doesn't happen all that often - sometimes, sure, but it's a small percentage of the total number of queries I need. In most cases (in my experience anyway) this type of query is used in a reporting type of situation, where a flatter structure (such as a Map) will do. (To any OOP police reading this: I don't really care if it's not a true Object-Oriented solution, it's still a solution, and I will bill for it anyway.) In the few cases where I have had to do this, if performance is not critical, multiple queries work adequately; if performance *is* critical, a RowHandler will provide pretty darn good performance. If it's a show-stopper for you, feel free to fix-up the code over the weekend, attach it to the JIRA issue with some test cases, and email me. I'll review it and commit it - I'd like to see this one resolved. Larry On 4/13/07, Mark Volkmann <[EMAIL PROTECTED]> wrote:
Suppose I have person, address and phone tables. address has a foreign key to person. phone has a foreign key to person. A person can have multiple addresses and multiple phones. I want to create an iBATIS mapped select that retrieves a person and all their addresses and phones. This has been referred to as the "1:N + 1:M" problem and it's not currently supported by iBATIS. See http://issues.apache.org/jira/browse/IBATIS-396. My question is why this doesn't seem to be a big issue for iBATIS users. I can think of two possibilities. 1) You haven't needed this functionality. Perhaps the situation doesn't exist in your databases. 2) You've worked around this by writing custom Java code that performs multiple queries and populates the "top" object (Person) with lists of the "subordinate" objects (Address and Phone). I'm a consultant trying to persuade a client to use iBATIS and they are wondering why lack of support for this isn't an issue for others.
