Adding to a bidirectional hasMany relationship without using addTo... does it avoid the typical hasMany performance drawbacks?

[gatherer]

Imagine the classical example of a bidirectional hasMany association:

class A {
    static hasMany = [b: B]
}

class B {
    static belongsTo = [a: A]
}

It has been discussed in this forum and in some other blogs that using something like: aInstance.addToB(bInstance)
will load all related Bs to aInstance to check for unicity and possibly order.

What about just creating a B instance directly such as: bInstance = new B(a: aInstance).save()

Does it avoid the performance problems while at the same time having all the hibernate advantages such as having the relationship mapped letting you do joins in HQL?

Any drawbacks?

[longwa]

If you don't care about order or uniqueness, you can define you collection of B's as a Bag by adding 

Collection b

According to the docs "Since uniqueness and order aren't managed by Hibernate, adding to or removing from collections mapped as a Bag don't trigger a load of all existing instances from the database, so this approach will perform better and require less memory than using a Set or a List."

Then I think you can safely use whatever methods you want for making the associations.

-Aaron

On Mon, Jun 18, 2012 at 6:21 AM, gatherer <[hidden email]> wrote:

Imagine the classical example of a bidirectional hasMany association:

class A {
   static hasMany = [b: B]
}

class B {
   static belongsTo = [a: A]
}

It has been discussed in this forum and in some other blogs that using
something like: aInstance.addToB(bInstance)
will load all related Bs to aInstance to check for unicity and possibly
order.

What about just creating a B instance directly such as: bInstance = new B(a:
aInstance).save()

Does it avoid the performance problems while at the same time having all the
hibernate advantages such as having the relationship mapped letting you do
joins in HQL?

Any drawbacks?

--
View this message in context: http://grails.1312388.n4.nabble.com/Adding-to-a-bidirectional-hasMany-relationship-without-using-addTo-does-it-avoid-the-typical-hasMany-tp4630293.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[burtbeckwith]

See http://burtbeckwith.com/blog/?p=1029 for some issues around using Bags.

Burt

Aaron Long wrote

If you don't care about order or uniqueness, you can define you collection
of B's as a Bag by adding

Collection b

According to the docs "Since uniqueness and order aren't managed by
Hibernate, adding to or removing from collections mapped as a Bag don't
trigger a load of all existing instances from the database, so this
approach will perform better and require less memory than using a Set or a
List."

Then I think you can safely use whatever methods you want for making the
associations.

-Aaron

[gatherer]

I had already read that very informative article Burt.

What I am trying to say is that even when using grails 1.3.7 (no bags) and not using a join table (B has a reference to A), if I don't use the "addTo" method but create a B instance directly (new B(a: aInstance)), when I inpect the SQL traces I don't see grails loading all the instances from the relationship, just an insert.

As a possibly positive side effect, A doesn't get its version number updated, and you didn't like that about bags in your article.

What I am trying to achieve with this is having the same speed as your "manage the relations yourself" method you proposed to replace hasMany relationships while at the same time having the relationship mapped in hibernate so that I can fetch join in HQL, cascade delete, etc.

I was just wondering if there is any drawback about not using the "addTo" method to add to hasMany relationships or if it is just plain wrong.

[gatherer]

Any thoughts on this idea?