mapping to objects that have multiple list properties

[Mark Volkmann <ma...@ociweb.com>]

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.

Re: mapping to objects that have multiple list properties

[Larry Meadors <lm...@apache.org>]

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 <ma...@ociweb.com> 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.
>

Re: mapping to objects that have multiple list properties

[Jeff Butler <je...@gmail.com>]

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 <ma...@ociweb.com> 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.
>