CODEWITHSUNDEEP
grailsgrails-ormrelationship
Zobbl
Zobbl

Reputation: 479

Grails hasOne unidirectional

Currently I'm having some trouble, creating an unidirectional relationship in Grails.

I have a class Toilet with an Attribute Address. This Address is a seperate class. The Address can - theoretically - still exist, if the Toilet-Object, which the Address is associated with, gets deleted. The toilet will stay, too, if the address gets deleted.

GORM's hasOne is not what i need, because it creates a bidirectional relation.

Defining an attribute of the type class only results in a non-persisted Address (despite it's own table) - that means, the association of the Address to the Toilet-Object doesn't exist

I'm not really familiar with these kinds of relationships, so I would really appreciate a solution or another way to accomplish my goal

Hope my problem is clear - if not comment, and I will try to add further explanations

Upvotes: 0

Views: 2225

Answers (4)

codewandler
codewandler

Reputation: 557

Why not have a class which models the association ?

class ToiletAddress {
  Toilet toilet
  Address address
  ...
}

... and then simply wrap your logic into a service where you assign addresses to toilets, and delete toilets or addresses.

Using constraints you can define what kind of association it is. eg 1-1, 1-n (both sides), and n-m

static constraints = {
  address unique: ['toilet']
  toilet validator: {val, obj -> ... }
}

Upvotes: 0

Zobbl
Zobbl

Reputation: 479

Found the solution.

What I left out, was the implemenation of an interface in the Toilet class.

The problem was (as a reminder) that the relationship of the address within the toilet class wasn't saved to the database.

This was a problem of the interface itself - in this interface, getters and setters were defined and had to be implemented (the way an interface works - obviously). The problem here was, that the setter of the Address-Attribute expected the Type IAddress.

I overloaded the setter to also receive a parameter of the type Address.

With this change, the relationship between Toilet and Address is saved correctly to the database - the ID of the Address is saved in the table of the Toilet.

I think the definition of the setter is just a mistake (i have no influence on the interface), but with this workaround i can get it to work anyways

Hope this explanation helps others too.

Upvotes: 0

nate_weldon
nate_weldon

Reputation: 2349

taken from

http://grails.org/doc/1.0.x/guide/5.%20Object%20Relational%20Mapping%20(GORM).html

5.3.3 Understanding Cascading Updates and Deletes

It is critical that you understand how cascading updates and deletes work when using GORM. The key part to remember is the belongsTo setting which controls which class "owns" a relationship. Whether it is a one-to-one, one-to-many or many-to-many if you define belongsTo updates and deletes will cascade from the owning class to its possessions (the other side of the relationship).

If you do not define belongsTo then no cascades will happen and you will have to manually save each object.

So.....if you do not use belongsTo then if you manually save each object you should not have a problem.

Upvotes: 1

ataylor
ataylor

Reputation: 66059

If the address on Toilet is a simple association without a hasOne or belongsTo mapping, then no operations will be cascaded.

That means you'll have to save the address, assign it toilet.address, and save the toilet.

Upvotes: 0

Related Questions