What is the different in GORM between
class Books {
Author author
}
and
class Books {
static belongsTo = [author: Author]
}
Does cascading rules changes in these two approaches? Also, when to use belongsTo and more importantly, when not to use belongsTo in Grails ?
Yes, belongsTo is intended for controlling cascades of saves and deletes. You may reference the full documentation here http://docs.grails.org/latest/ref/Domain%20Classes/belongsTo.html but to summarize (and in case the URL dies someday):
Use belongsTo to indicate ownership. Saves or deletes to the parent will cascade to the child. In your example, if the Author is deleted, his Books will be too (assuming Author hasMany Books
Do not use belongsTo if you just want to indicate a relationship with no ownership on either side and no automatic cascading of saves or deletes.
Related
Say we have the following two domain classes:
class Book {
static belongsTo = [author: Author]
}
class Author {
static hasMany = [books: Book]
}
No if an Author is initialized with several books and Author.save() is called then the save cascades to Book and both Author and Book instances are saved into db.
However I can't find anywhere in documentation if the mentioned operation will be done transactionally or not.
Any idea?
Any resource to check ?
The answer depends on where the save is done. Is it done in a controller action marked as transactional? Is it in a service which uses transactions by default? Or is it done somewhere else where there is no transaction.
If the save is done somewhere that supports transaction (two examples above) then yes, it will be. Otherwise, no it won't be.
I have got a domain class Track
class Track{
static belongsTo = [createdBy: User, modifiedBy: User, Course]
}
But its giving me error, Finally i dont want to have course object[course: Course] but only have to specify that it belongs to Course [Course]. How to do this
I think you are using the GORM associations a bit too extensively. belongsTo indicates ownership, and the GORM associations, in general, indicate more about the cascading relationship between objects than anything else.
If you only want to associate User with your Track, you just need to have the createdBy and modifiedBy fields, which don't need to be in any special sort of association. Then you would have static belongsTo = [Course] to show that the Course owns the Track, meaning that if you deleted the Course, that the Track would get deleted as well.
Here's the class I think you are looking for:
class Track {
User createdBy
User modifiedBy
static belongsTo = [Course]
}
I am having to two domain classes Order and Stock. When stock is sold I am creating an entry in the child table StockOrder which contains information about the Order(order_id) and Stock(stock_id) and noOfStockSold.
In my current design I coded the StockOrder close to Stock table. You can see this below.
Class Stock {
String stockName
BigDecimal quantity
List stockOrderList
static hasMany = [stockOrderList: StockOrder]
}
class StockOrder {
Stock stock
Order order
BigDecimal noOfStockSold
static belongsTo = [Stock]
}
class Order {
List saleLineItemList
static hasMany = [saleLineItemList: SaleLineitem]
}
Am I doing to correctly from ERP prespective. How to relate Order to Stock sold?
Is it ok if I tie StockOrder to Order also by doing static belongsTo = [Stock,Order]
Is there any better way of doing it or any improvements?
I would start by reading these:
http://grails.org/doc/2.0.x/ref/Domain%20Classes/belongsTo.html
http://grails.org/doc/2.0.x/ref/Domain%20Classes/hasMany.html
Basically you use the belongsTo and hasMany to describe bi-directional relationships. This allows you to cascade delete objects if you so desire. I would imagine in an ERP system that you wouldn't want cascading functionality because if you delete a Stock you probably don't want to delete all the associated StockOrder. I would probably keep the hasMany side of the relationship and remove the belongsTo since you're already associating a StockOrder to a Stock and an Order.
In Grails belongsTo allows one domain class to establish a cascading relationship with another domain class. There are two styles of relationships when using belongsTo: Reference and No Reference. Reference creates a property on the owned object while No Reference merely establishes an invisible GORM relationship.
Example parent domain-class:
class Car {
Engine engine
}
belongsTo without Reference property:
class Engine {
static belongsTo = Car
}
belongsTo with Reference property:
class Engine {
static belongsTo = [car:Car]
}
Not to hard right, however the trouble for me starts when we start using multiple belongsTo references:
belongsTo with multiple back references:
class Engine {
static belongsTo = [car:Car, user:User]
}
multiple belongsTo relationships without property references:
class Engine {
static belongsTo = [Car, User]
}
Here's the problem, how do I mix the two above styles?
Say I want a property reference for the User but not for the Car, how would I write that belongsTo call?
Any information on how to mix No Reference relationship links with Reference property in a single domain class would help.
Links:
Using Grails Object Relational Mapping (GORM)
belongsTo - grails.org
This question reposted by me on the official Grails forum
class Engine {
User user
static belongsTo = [Car, User]
}
That said, I always use the map (reference) syntax over the list (no reference) syntax because I like mine to be bi-directional.
In an ordinary one-to-many mapping the "one"-side is the owner of the association. Why would anyone use the belongsTo-mapping for such a mapping? Am I missing some side-effect of specifying belongsTo?
In other words: what are the effects of specifying a belongsTo-mapping in GORM vs. not specifying it?
Whether to specify belongsTo depends upon the type of referential action you want.
If you want Grails to do On Delete, CASCADE referential action, then DO specify belongsTo. If you want Grails to do On Delete, RESTRICT referential action, then DON'T specify belongsTo.
e.g.
// "belongsTo" makes sense for me here.
class Country {
String name
static hasMany = [states:State]
}
class State {
String name;
// I want all states to be deleted when a country is deleted.
static belongsTo = Country
}
// Another example, belongsTo doesn't make sense here
class Team {
String name
static hasMany = [players:Player]
}
class Player {
String name
// I want that a team should not be allowed to be deleted if it has any players, so no "belongsTo" here.
}
Hope this helps.
Specifying belongsTo allows Grails to transparently cascade updates, saves and deletes to the object's children. Without belongsTo, if you attempt to delete a master record, you'll end up getting a foreign key violation if it has any details it owns.