• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

JPA question on OneToMany MapBy vs JoinColumn

 
Ranch Hand
Posts: 654
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

Playing around with SpringData JPA, I have a problem with OneToMany JoinColumn

In the following code


return data for account is  : AccountFund [acountId=1111, accountName=AccountCavanagh, funds=[Fund [fundId=111110, fundName=FundCav1]]]

Returning the data for both funds I have :
Fund [fundId=111110, fundName=FundCav1]
Fund [fundId=111111, fundName=FundCav2]

so the fund data is being added to the repo, but FundCav2 is not being added to the FundAccount set.  

My Question is when  I use a JoinColumn do I have to take the account out of repo and add it then save it.

With MappedBy the code above would add the FundCav" to the set, I would think using  JoinColumn it would handle adding to the set the same way through the fundrepo





Thanks for any help
 
Marshal
Posts: 72612
317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please don't use l as a suffix to denote a long literal; as the Java® Language Specifiaction (=JLS) recommends, always use L, please.
Mr Chad would say, “Wot, no equals() method?” You can only get classes in the Collections Framework to work correctly if you override hashCode() and equals() correctly.
 
Tony Evans
Ranch Hand
Posts: 654
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply I overwrote Equals and Hash for both entities still not updating account with FundCav2



 
Saloon Keeper
Posts: 23515
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Please don't use l as a suffix to denote a long literal; as the Java® Language Specifiaction (=JLS) recommends, always use L, please.
Mr Chad would say, “Wot, no equals() method?” You can only get classes in the Collections Framework to work correctly if you override hashCode() and equals() correctly.



The problem with using "l" is that it's often hard to tell "l" from "1", depending on the font used to render it. "L" is more obvious.

But more importantly, since all non-index fields of a database row instance are potentially mutable, it's only by comparing the index field(s) and only the index fields that you can tell the difference between one row that has been changed and two entirely different rows. And since hash value depends on equals(), that method also requires overriding.

In JPA, entity instances can exist in one of two contexts: attached and detached. Instances newly-fetched are attached. To persist new or changed instances you have to be attached. To fetch across joins when the relationship is LAZY, you must also be attached. Detached instances are merely POJOs for all intents and purposes and cannot participate in attached operations. They must be re-attached before doing that - and - fair warning - when you take an object and re-attach it, the attach method will generally return a different instance of that object, and not modify any invisible magic within the original POJO that would make it be attached. Thus, the pre- and post- attach instances are equals(), but not "==". You probably are not detaching, but I figured it's worth pointing out (I do detach stuff before passing it to higher levels of application logic).

I mention attachment, because you asked about "saving" a dependent object and that's a case where you sort of do save stuff.

More likely you're making the common mistake of thinking you can only fetch/update selected dependent objects. When you fetch a parent and you have eager fetch, it fetches all children, and that in turn fetches any eager connections from the children outwards. You can potentially suck the entire database into RAM with eager fetch if you're not careful. Lazy fetch can be more selective, but there's a "gotcha". Lazy fetch collections are proxies for the fetch mechanism. If you're going to fetch a parent and modify a child, you do have to manually pull in the entire collection or you can lose child rows when you update.

Finally, when updating, you do have to manually persist out both parent and children unless you have automatic cascading enabled.
 
Tony Evans
Ranch Hand
Posts: 654
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok forget those entities to make it bidirectional @JoinColumn should be in the ManyToOne

so thsi works birectional




 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic