Hey Mark,
You seem to be missing the 'groupBy' attribute. Try this:
select id=selectClientAndDealingsWithJoin parameterClass=java.lang.Long
resultMap=clientAndDealingsMap *groupBy=CRoid*
Not 100% sure that will solve your problem, but it should certainly get
you closer :-)
Kris
Ralph, Mark
What is n+1?
.V
friendVU admin wrote:
What is n+1?
.V
n++! :-P
It's when each child object in a complex query has to be selected
seperately. If 'parent' has 10 'children', you end up with 10+1 select
statements being issued. See the developer's guide under 'Avoiding N+1
selects' for the full lowdown.
What about relationships from the child up to the parent? Are they also
classified as N+1?
Suppose we have child table with a fk of parent_id.
if I do:
SELECT * from CHILD
I'll get a column with parent_id with values.
Now suppose I also want details pertaining to the parent_id along with
Well, I think you need only simple join in your sql, no extra features of
ibatis needed:
select * from CHILD, PARENT where parent_id=PARENT.id;
am I right?
Michal Malecki
What about relationships from the child up to the parent? Are they also
classified as N+1?
Suppose we have child table
Ok, the flip-side of this approach is that you increase the size of the
returned result by N*(size of the lookup).
So if the lookup is 10 bytes and you are fetching 10 records of the
child, your payload size is 100 bytes
instead of 10 bytes. ( I wonder if JDBC makes some internal
Qualification:
Ok, the flip-side of this approach is that you increase the size of
the returned result by N*(size of the lookup).
Where N = number of records with *unique* parents.
Kris Jenkins wrote:
friendVU admin wrote:
What is n+1?
.V
n++! :-P
It's when each child object in a complex query has to be selected
seperately. If 'parent' has 10 'children', you end up with 10+1
select statements being issued. See the developer's guide under
'Avoiding N+1 selects' for
That's question which I am asking to myself for some time now. I am afraid
that it is strongly dependant on the case (db engine, size of parent and
child, how many children has parent). Using n+1 killer (groupby in ibatis)
is much cleaner in Java code, co I think it's better, unless developing
Without groupBy in your resultMap, you'll end up with 3 parent
objects, each with one child. What you wanted was 2 parents, one with
three children.
Sorry, that should read 'end up with 4 parent objects'. I'm clearly
having a bad day...
Not exactly - Abdullah fliped the problem and wanted to selected children,
and parent for each other. Then you don't need group by. When you want
parent and list of children - then of course you are right.
Michal Malecki
Well, I think you need only simple join in your sql, no extra features of
Which I could do with a join on SQL side. I can't see how this is
something I'd use or how it' scale, but I guess somone uses it.
THANKS for the education.
.V
Kris Jenkins wrote:
The N+1 selects problem is when you query for n parents, and you need
one extra query for the children.
The reason is explained well in the SQLMaps documentation:
Lazy Loading vs. Joins (1:1)
ItÂ’s important to note that using a join is not always better. If you are in
a situation where it is rare to
access the related object [-the Child-] then it might actually be faster to
avoid the join and the
For all of the great information you've provided, you did not provide
the exception.
Also, due to the amount of information you have, you might want to
open a JIRA ticket so we can manage it better.
Cheers,
Clinton
On Tue, 8 Feb 2005 22:58:53 -0600, Mark Nabours
[EMAIL PROTECTED] wrote:
I see.
I am not sure if that is good advice. I think if you click on a table
you get the detail, that makes sense.
Else... row processing is not for SQL, SQL is based on relational
algebra and Set Theory and Venn diagrams, ie... you work on a set of
records, not cursor processing.
I am sure
Ahhh...okay. Even without the exception, I can see the problem here.
First, please understand that iBATIS is NOT an O/R Mapper, so it
differs greatly in its behavior. Your assumption that N+1 and Lazy
Load will work the same way is somewhat more applicable to an ORM than
it is to iBATIS.
Clinton,
You are right about the exception -- the simple example below does not
throw one.
The exception only will occur when the objects within the list contain
primitive properties I believe. For instance, if the id property on the
item object was an int and my memory serves me correctly,
Hi Jeff,
You're absolutely rightbut I thought this is what it didafter
all, we just use HashMaps (which handles collisions) as the underlying
implementation.
When the developer's intention is not equal to the application
behaviour, that is generally indicative of a bug. :-)
...and I
Not from my experience with it (as you see in the FAQ)
You do, however, need to a groupBy to the parent resultMap (in your case
clientAndDealingsMap).
Move the groupBy that Kris sent to that resultMap and see what happens.
Just out of curiousity though.
If you print on the size of List clients
Jeff,
Do you know if this only affects the latest version (2.0.9) with LRU
caches? Have you tried with other types of caches as well?
Thanks,
Aitor
Done (IBATIS-70).
Thanks for the quick response!
Jeff
[EMAIL PROTECTED] 2/9/2005 9:13:51 AM
Hi Jeff,
You're absolutely rightbut I thought this is what it didafter
all, we just use HashMaps (which handles collisions) as the underlying
implementation.
When the developer's intention
I wonder one thing, which Abdullah and I have already mentioned - what if
parent is big and has a lot of children. We are getting through the net n
times parent record. The most efficient would be, I think, to make 2
selects - one for the parent records, and one for all of the children, plus
the
Clinton,
I can see the point when friendlyVU (???) spoke about getting details of
the appropriate parent.
Appropriate being the operative word. (Lazy loading)
In all our database applications, we have *seldom* required the need to
work off a list of
Categories then require to display (use)
Hi all.
The following does insert only 4 records, skipping the first
one.
If I dont use batch, it inserts 5 perfectly.
Has anyone seen this problem in the past?
Thank you.
Kyunam
try {
_sqlMapClient.startBatch();
for (int i
= 0; i 5; i++) {
Guysthis is the kind of fix I would normally implement within 24
hours. Unfortunately our SVN repos isn't up yet. We're stuck.
I may create a patch for you. Let's wait a bit to see what happens.
Clinton
On Wed, 9 Feb 2005 08:26:07 -0700, Clinton Begin
[EMAIL PROTECTED] wrote:
It
The 16 way join and put the DB in App. server RAM?
My experience on several terabytes DBs has been opposite, I hope you
trust me too :-D .
Getting a list of categories, then you click on a catagory and get a
list of products, then you click on a product and get a list of
components is much
Hi Abdullah,
N+1 selects the other way around is a 1:1 or an M:1 relationship
(child has ref to parent), which iBATIS has always supported through
nested property mappings in the resultMap...for example:
result property product.id columnPRODUCT_ID /
result property product.name
Weirdadd it to JIRA please.
Clinton
On Wed, 9 Feb 2005 09:38:54 -0600, Kyunam Kim [EMAIL PROTECTED] wrote:
Hi all.
The following does insert only 4 records, skipping the first one.
If I don't use batch, it inserts 5 perfectly.
Has anyone seen this problem in
Vic, probably isn't an issue for you since you only use HashMaps ;)
On Wed, 09 Feb 2005 08:12:32 -0600, Vic Cekvenich [EMAIL PROTECTED] wrote:
Which I could do with a join on SQL side. I can't see how this is
something I'd use or how it' scale, but I guess somone uses it.
THANKS for the
I dont think that the current implementation will work for this but I
was looking for some best practices on how to do it.
Parent Class A has n number of List properties that all come for their
own tables.
A from table_a
List of B from table_b
List of C from table_c
.
If you can join the data into a single resultset with repeating
groups, the N+1 solution will work, no matter how the collections are
arranged.
As long as you group by some column in table_a, you can separately map
2 collections on the same class.
This will work.
Try it out!
Clinton
On Wed,
Thanks for that help guys - the missing groupBy was the culprit all right.
it works great!
As you suspected - without the groupBy I was getting back one client for each
of the query results.
-Original Message-
From: Chen, Tim [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 9 February 2005
32 matches
Mail list logo
