What is the difference between these 2 hasOne syntax ?
class Project {
.......
............
static hasOne = Employee
// static hasOne = [employee:Employee]
}
I have noticed that the first one creates a many-to-many relationship(3 tables) but it should be many-to-one(2 tables) as in the Employee class I have:
static hasMany = [projects:Project]
The second one works fine:
static hasOne = [employee:Employee]
I am using Grails 2.2.0 and I even tried in Grails 2.0.3 but the result is same.
Thanks
I don't think that the 1st variant makes any sense at all. You could define a belongsTo back-ref without specifying a field for that, and this could be used for cascading things for example.
The case with hasOne is quite the opposite: you want to have an explicit one-to-one, which makes it logical to specify the reference explicitly:
static hasOne = [employee:Employee]
The most common case to use hasOne is when you want to have one-to-one relation, but you don't want to modify the domain class you are referencing, so that you don't have to introduce more complexity and/or migrate the old table.
To my mind, the 1st variant is useless and doesn't produce an error due to... lack of GORM developers time? ;)
Related
What is the difference between mappedBy and belongsTo for m-m relationships in Grails? How can the two be used in a same Domain?
I think there are 3 with 1 that has two formats:
There is belongsTo:
belongsTo=[something:Something] and belongsTo=Something or belongsTo=[Something,Another]
There is Something something
and finally hasOne=[something:Something]
When you declare Something something this actually creates a table cell called something_id
When you declare belongsTo=[something:Something] something_id isn't created and I think if I understand correctly that relationship is now managed by hibernate.
Points of reference Explain belongsTo in Grails and Grails hasOne vs. belongsTo
So in short one you manage the relationship through db and other is managed by hibernate.
How can the two be used in the same domain ?
Why would you need both if they are both pointing to the same parent ?
You can use either method for any relationship the belongsTo is a hibernate control mechanism telling it what / which way the relationship is so therefore the Parent must have Child child mapping
Where as Something something or Parent parent really has none of the above requirements. Hope it is making sense
Hi I have a simple problem.
My domain class is like this:
class Example {
long seq
hasMany = [example_array: ExampleData]
long count
}
class ExampleData {
String type
long description
static belongsTo = Example
static constraints = {
}
}
This results in 3 tables, like a many to many relation.
Why is this?
Thanks
The reason for the extra table is that you've modeled the relation only in one direction - an Example can access its ExampleData instances via the example_array Set that's added to your class bytecode because of the hasMany property, but an ExampleData instance has no way to reference its owning Example.
You added a belongsTo property, but only specified the class name. That's sufficient to configure ownership, cascaded deletes, etc. but doesn't provide a property in the class to access the Example instance.
If you change it to the other supported syntax it will work as you expected:
static belongsTo = [example: Example]
Here example will end up being the name of an Example property (and you can change it and/or example_array to any valid property name), which is basically the same as declaring
Example example
Now that both sides can access the other, the relationship is bidirectional and you no longer need the third table. That's because a 1-many is typically implemented using a foreign key in the child table, in this case in the table for ExampleData that points to the table for Example. That wasn't possible without a property in the class to wire up to that column, so the join table was necessary.
I believe that you have to map the BelongsTo, like this:
static belongsTo = [example:Example]
Hope it helps :)
From the definition of hasMany Grails will, by default, map this kind of relationship with a join table.That join table is the 3rd table you mentioned.No need to worry about that.
Well the one-to-many relationship is constructed by having additional table (i.e. Example_ExampleData) containing two columns each id fields from tables of the entities forming the relationship(i.e. Example and ExampleData).
The newly added table is child to parent tables – Example and ExampleData.
So in your case when you run your application the 3rd table gets created by Grails by default as your table relationship falls under the one-to-many relationship.
I am new to Grails and I would like to know what impacts exist on generated code, db schema, GORM, etc. when using Grails' predefined static properties on domain classes like hasOne, hasMany and belongsTo.
For example, would hasOne force a singleton pattern somewhere?
Taking a quick look at both generated code and database, I didn't find many clues.
belongsTo forces a save of the child class when saving the parent class
hasOne creates a one-to-one / one-to-many mapping in the DB (no association table)
hasMany is used for one-to-many (is in one of the classes) / many-to-many (if in both classes, with association table)
Is there a difference between using hasMany
static hasMany = [objects:Object]
and adding a collection of object
Set objects
There is definitely a difference between using:
static hasMany = [objects:Object] and List objects
static hasMany = [objects:Object] is stored in a java set there you cannot have duplicate objects. Furthermore, the objects will not be in order of insertion.
List objects is a typical java list which will allow duplicates as well as be able to maintain order.
I believe there are more differences but I am just posting the differences I am aware of.
In my service I create a "root" object which has associations to many objects which in turn have associations to many more objects and so on. Once the root object is completely built and ready to be saved I would like to call save on the root object and have all associated objects all the way down be saved as well. Right now I have a recursive method called deepSave which does this. Is there a better way?
If you use belongsTo GORM automatically defines the cascading for you. This means: If A belongsTo B then A will be saved when B is saved. However, it is possible to define cascading without using belongsTo (if this does not fit to your domain model):
class Author {
static hasMany = [books: Book]
static mapping = { books cascade: 'all-delete-orphan' }
}
You should have a look at the cascade property provided by GORM. Additionaly the hibernate documentation provides more detailed information.