One of the reasons to use iBATIS is to avoid creating deeply nested object graphs that you won't use and don't need. My guess is that this is one of the reasons it's not such a big issue to iBATIS people. Not that this is very deeply nested, but maybe you know what I mean. Truthfully - how often do you really need a fully filled out Person object?
This leads me to another thought - I think that most web applications are, in effect, transaction scripts rather than truly domain driven. In a transaction script, you're much less concerned with filling out complete object graphs. I'm not saying this is desirable, just a fact in the projects I've seen. Another reason may be that it might not be that big a deal to run a second (or N more) queries. With connection pooling, prepared statement caching in application servers and JDBC drivers (and now iBATIS too), and various other caches in effect in multiple layers of software and hardware, I sometimes wonder if an N+1 query is really that much worse than 1 query with a metric ton of duplicated data. It would be interesting to see some benchmarks about that in some modern environments. Maybe we're all obsessiong about nothing. Jeff Butler 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.
