• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Should I use many to one unidirectional mapping for this or bidirectional one to many?

 
Monica Shiralkar
Ranch Hand
Posts: 873
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to know whether I should go for many to one unidirectional mapping for this or bidirectional one to many for the below case:


I have a Product table and Category table. Many Products can have a single Category. If I have a one to many unidirectional mapping between Category and Products, then on doing a save operation on Category the Products will also get saved(If cascading is used). However I want something different. I want the relationship to be such that on saving the products , it should also save in the category table. This will happen if I use unidirectional many to one mapping between Products and Category. This will also happen if I have a bidirectional one to many mapping between category and products. Which one of the two approaches should I go for? Thanks
 
Paul Clapham
Sheriff
Posts: 21559
33
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Monica Shiralkar wrote:I want the relationship to be such that on saving the products , it should also save in the category table.


What do you need that for? Normally when you add a product to a category, it doesn't do anything to the category which requires the category to be saved. So does your application change a category in some way when you add a product to it?
 
Monica Shiralkar
Ranch Hand
Posts: 873
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks

What do you need that for? Normally when you add a product to a category, it doesn't do anything to the category which requires the category to be saved. So does your application change a category in some way when you add a product to it?


I want to give the administrator access to adding produtcs .So if he adds products, the parent (Category) should also be saved.I want to use the cascading such that on saving the child table, the parent too gets saved.(cascade = CascadeType.ALL)
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Monica Shiralkar wrote:
So if he adds products, the parent (Category) should also be saved.I want to use the cascading such that on saving the child table, the parent too gets saved.(cascade = CascadeType.ALL)

That's taken care of by cascade regardless of whether your relationship is unidirectional or bidirectional so don't use the cascade requirements to decide whether your relationship should be unidirectional or not. Rather think about how you are going to be using this relationship in your application.
Will you be needing to have/use a method category.getProducts(). If you do then you need your category entity to know about products, if not then you don't need a bidirectional relationship.
 
Monica Shiralkar
Ranch Hand
Posts: 873
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks

That's taken care of by cascade regardless of whether your relationship is unidirectional or bidirectional


As per my understanding this is half true.Please correct me if I am wrong. In case of unidirectional relationship, if cascade is used in one to many relationship between category and product, on saving the category, the product will get saved but vice versa is not true.

Will you be needing to have/use a method category.getProducts(). If you do then you need your category entity to know about products, if not then you don't need a bidirectional relationship.



Yes, but this I am able to achieve already in unidirectional one to many relationship without using bidirectional relationship.



 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your relationship should really be owned by Product (it's the one whose table will have a foreign key to category ). In my reply I had assumed that that's where it is and I see now that it isn't. So unidirectional relationship will be on the Product entity. Then apply the statements I said above.
 
Monica Shiralkar
Ranch Hand
Posts: 873
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your relationship should really be owned by Product


I did not understand what does 'owned by' means over here. My main confusion at this stage is that how to decide whether bidirectional relationship should be used when the same thing is being achieved in unidirectional mapping too. Is there anything which cannot be achieved in unidirectional mapping which can be achieved only using bidirectional mapping? As per the discussion so far in this thread we have talked about no such thing which is possible only in bidirectional and not possible in unidirectional mapping.


thanks
 
E Armitage
Rancher
Posts: 989
9
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Monica Shiralkar wrote:
Your relationship should really be owned by Product


I did not understand what does 'owned by' means over here.

The owning side is very important to decide in any mappings that you do. It is the entity where the relationship is defined and more importantly for XtoOne relationships it's the side where the foreign key will be created in the database. For your tables you will have a Product table and a category table. there will be nothing in the Category table that says that this table is related to the Products table. The products table will have a foreign key to the Category table. So the Product table owns the relationship. If you use a bidirectional relationship the Category side of the relationship must state that it doesn't own the relationship by specifying the ownedBy property pointing to the Product which owns the relationship.


Monica Shiralkar wrote:
Your relationship should really be owned by Product


. My main confusion at this stage is that how to decide whether bidirectional relationship should be used when the same thing is being achieved in unidirectional mapping too. Is there anything which cannot be achieved in unidirectional mapping which can be achieved only using bidirectional mapping? As per the discussion so far in this thread we have talked about no such thing which is possible only in bidirectional and not possible in unidirectional mapping.


thanks

If you have a bidirectional relationship you are able to do both product.getCategory() and category.getProducts(). With a unidirectional relationship you can only do one of those.
 
Monica Shiralkar
Ranch Hand
Posts: 873
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the explanation. Based on the discussion in this thread, below is my understanding:


If a bidirectional One to Many mapping is used:

This is the combination of one to many unidirectional mapping and many to one unidirectional mapping.

We can do anything with bidirectional one to many mapping that we can do with one to many unidirectional mapping or many to one unidirectional mapping.

We can do both product.getCategory() and category.getProducts(). Does the same apply for save operation too?


If unidirectional many mapping is used:

We can only do fetch operation from the owing side but not from the other end. Does the same apply for save operation too?



My only doubt now is :

With bidirectional one to many mapping we can do everything that we can with unidirectional one to many mapping but the vice versa is not true. So in that case anyone would prefer a bidirectional one to many mapping and why would someone prefer a many to one unidirectional mapping over bidirectional one to many mapping where you can do everything that you can with the other option.
 
Paul Clapham
Sheriff
Posts: 21559
33
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sure, the bidirectional mapping can do more than the unidirectional mapping. But that additional functionality doesn't come for free -- you have to put extra foreign keys in your database to make it work. And if you don't actually need the additional functionality then maintaining those extra foreign keys is a cost without any benefit. Generally database administrators don't approve of making their databases do work for no reason, and rightly so.

Similarly there's a programming principle named YAGNI (You Ain't Gonna Need It) which suggests that you shouldn't implement features which you aren't going to use. Because when you do that, you have to maintain those features even though nobody is using them. Again, a cost without any benefit.

So that's why you should consider which directional mapping you actually need for your application and only implement that.
 
Monica Shiralkar
Ranch Hand
Posts: 873
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. I got the point. This also cleared my other similar doubts that had got into my mind due to no knowledge about YAGNI.


 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic