Please consider the following (partial) class:
#Entity
#Table(name = "account", catalog = "storeman", uniqueConstraints = #UniqueConstraint(columnNames = "email"))
public class Account implements java.io.Serializable {
private Integer id;
private String email;
private String displayName;
...
#Id
#GeneratedValue(strategy = IDENTITY)
#Column(name = "id", unique = true, nullable = false)
public Integer getId() {
return this.id;
}
#Column(name = "email", unique = true, nullable = false, length = 80)
public String getEmail() {
return this.email;
}
#Column(name = "display_name", nullable = false, length = 50)
public String getDisplayName() {
return this.displayName;
}
public static Account lookup(String email, Session session){
return (Account)
session.createCriteria(Account.class)
.add(Restrictions.eq("email", email))
.uniqueResult();
}
}
As you can see, it maps the account table of mydb that uses id as the primary key. However, when searching for Account in db I want use the email as selection criteria. To do so I have added a static method named lookup that performs my query. That works fine as far as I can see.
However I would like to ask whether that kind of approach is good practice when working with hibernate (dynamic web project using JDBC) or not and what kind of issues this can bring (if any).
Passing a session (or EntityManager, or pretty much any other service-object) around is not good practice in my book. Do this enough and you'll find yourself having trouble gathering and controlling where you call the database. The Service-objects should be the ones "using" the data-objects, not the other way around.
The correct thing to do is to create a Repository-service, which contains the means for getting the session/EntityManager, and also methods that perform the JPA-operations for this Entity/functional area.
So, I would move the query out of the Entity class, and into a Repository (the class where this method is called, the one that holds the session, sounds like a place to start.)
It would be better if you create a DAO class say AccountDAO for your model Account and move lookup method to AccountDAO.
Related
I would like to get some advice with a question that might make no-sense or may be it does. Let's have a profile object that has a set of Interest with a Many2Many relationship like this one:
#ManyToMany(fetch=FetchType.EAGER)
#JoinTable(name="profile_interests",
joinColumns={ #JoinColumn(name="profile_id") },
inverseJoinColumns = { #JoinColumn(name="interest_id") } )
#OrderColumn(name="display_order")
private Set<Interest> interests;
//GETTER AND SETTERS
public Set<Interest> getInterests() {
return interests;
}
public void setInterests(Set<Interest> interests) {
this.interests = interests;
}
public void addInterest(Interest interest) {
interests.add(interest);
}
public void removeInterest(String interestName) {
interests.remove(new Interest(interestName));
}
In my application controller I can add and delete interests in this way.
#RequestMapping(value="/save-interest", method=RequestMethod.POST)
#ResponseBody
public ResponseEntity<?> saveInterest(#RequestParam("name") String interestName) {
SiteUser user = getUser();
Profile profile = profileService.getUserProfile(user);
String cleanedInterestName = htmlPolicy.sanitize(interestName);
Interest interest = interestService.createIfNotExists(cleanedInterestName);
profile.addInterest(interest);
profileService.save(profile);
return new ResponseEntity<>(null, HttpStatus.OK);
}
#RequestMapping(value="/delete-interest", method=RequestMethod.POST)
#ResponseBody
public ResponseEntity<?> deleteInterest(#RequestParam("name") String interestName) {
SiteUser user = getUser();
Profile profile = profileService.getUserProfile(user);
profile.removeInterest(interestName);
profileService.save(profile);
return new ResponseEntity<>(null, HttpStatus.OK);
}
Eventually, a profile, a profile_interests and an interests table will be created. The profile_interest table will have a profile_id and an interest_id, right?
Now imagine that I also want to have other Sets of let's say: activities, passions OR hates, dislikes, tasks, vocations. I can repeat these same process again and again to cover the 6 new (activities, passions, hates, dislikes, task, vocation).
At some point one person may have and interest in Cars, whether other has a passion in Cars, a third one hates Cars and a fourth one say Cars are his Vocation.
If I create 7 different Sets of objects (interests, activities, passions, hates, dislikes, task, vocation) I will repeat many of them in all the tables.
-Is there any way to have a common (interests, activities, passions, hates, dislikes, task, vocation) table for the 7 set of objects, but 7 different intermediate tables (profile_interests, profile_activities, profile_passions, profile_hates, profile_dislikes, profile_task, profile_vocation) using the common table?
Thanks. I appreciate your help with a non-programmer. May be it is a problem well documented and already solved, I dont know.
PD: The Interest entity is here:
#Entity
#Table(name = "interests")
public class Interest implements Comparable<Interest> {
#Id
#Column(name = "id")
#GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
#Column(name = "interest_name", unique = true, length = 25)
private String name;
public Interest() {
}
In JPA 2 entities can be related in more than one ways - and it is perfectly legal. So, just like the interests, the (say) activities would be mapped in the Profile entity as:
#ManyToMany(fetch=FetchType.LAZY) // don't use EAGER unless you really want to :)
#JoinTable(name="profile_activities",
joinColumns={ #JoinColumn(name="profile_id") },
inverseJoinColumns = { #JoinColumn(name="interest_id") } )
#OrderColumn(name="display_order")
private Set<Interest> activities;
//GETTER AND SETTERS AS FOR interests
You haven't shown the Interest entity. If the relations are bidirectional, the Interest would have to have many different Set<Profile> fields, one for each relation it participates (interests, activities, ...). In that case the mappedBy attribute of the field in the Interest entity must point to the appropriate field of the Profile.
This also assumes that business-wise all the relations are between the same entities. A side-effect would be that the list where the user must pick an activity is the same as the list where the user must pick an "interest". If that it not exactly so, then you may have to do more.
I am writing a Spring Boot application that will use Hibernate/JPA to persist between the app and a MySQL DB.
Here we have the following JPA entities:
#MappedSuperclass
public abstract class BaseEntity {
#Id
#GeneratedValue(strategy = GenerationType.IDENTITY)
#JsonIgnore
private Long id;
#Type(type="uuid-binary")
private UUID refId;
}
#Entity(name = "contacts")
#AttributeOverrides({
#AttributeOverride(name = "id", column=#Column(name="contact_id")),
#AttributeOverride(name = "refId", column=#Column(name="contact_ref_id"))
})
public class Contact extends BaseEntity {
#Column(name = "contact_given_name")
private String givenName;
#Column(name = "contact_surname")
private String surname;
#Column(name = "contact_phone_number")
private String phone;
}
#Entity(name = "assets")
#AttributeOverrides({
#AttributeOverride(name = "id", column=#Column(name="asset_id")),
#AttributeOverride(name = "refId", column=#Column(name="asset_ref_id"))
})
public class Asset extends BaseEntity {
#Column(name = "asset_location")
private String location;
}
#Entity(name = "accounts")
#AttributeOverrides({
#AttributeOverride(name = "id", column=#Column(name="account_id")),
#AttributeOverride(name = "refId", column=#Column(name="account_ref_id"))
})
public class Account extends BaseEntity {
#OneToOne(fetch = FetchType.EAGER)
#JoinColumn(name = "contact_id", referencedColumnName = "contact_id")
private Contact contact;
#OneToOne(fetch = FetchType.EAGER)
#JoinColumn(name = "asset_id", referencedColumnName = "asset_id")
private Asset asset;
#Column(name = "account_code")
private String code;
}
And the #RestController, where an Account instance will be POSTed (to be created):
public interface AccountRepository extends CrudRepository<Account, Long> {
#Query("FROM accounts where account_code = :accountCode")
public Account findByCode(#Param("accountCode") String accountCode);
}
#RestController
#RequestMapping(value = "/accounts")
public class AccountController {
#Autowired
private AccountRepository accountRepository;
#RequestMapping(method = RequestMethod.POST)
public void createNewAccount(#RequestBody Account account) {
// Do some stuff maybe
accountRepository.save(account);
}
}
So the idea here is that "Account JSON" will be sent to this controller where it will be deserialized into an Account instance and (somehow) persisted to the backing MySQL. My concern is this: Account is a composition (via foreign keys) of several other entities. Do I need to:
Either create CrudRepository impls for each of these entities, and then orchestrate save(...) calls to those repositories such that the "inner-entitities" get saved first before the "outer" Account entity?; or
Do I just save the Account entity (via AccountRepository.save(account)) and Hibernate/JPA automagically takes care of creating all the inner/dependendent entities for me?
What would the code/solution look like in either scenario? And how do we specify values for BaseEntity#id when it is an auto-incrementing PK in the DB?
That depends on your design and specific use cases, and what level of flexibility you want to keep. Both ways are used in practice.
In most CRUD situations, you would rather save the account and let Hibernate save the entire graph (the second option). Here you usually have another case which you didn't mention, and it is updating of the graph, which you would probably do the same way, and actually the Spring's repository save method does it: if the entity is a new (transient) one, it persists it, otherwise it merges it.
All you need to do is to tell Hibernate to cascade the desired entity lifecycle operations from the Account to the related entities:
#Entity
...
public class Account extends ... {
#OneToOne(..., cascade = {CascadeType.PERSIST, CascadeType.MERGE})
...
private Contact contact;
#OneToOne(..., cascade = {CascadeType.PERSIST, CascadeType.MERGE})
...
private Asset asset;
...
}
However, you pay the penalty of reloading the object graph from the db in case of merge operation, but if you want everything done automatically, Hibernate has no other way to check what has actually changed, other than comparing it with the current state in the db.
Cascade operations are applied always, so if you want more flexibility, you obviously have to take care of things manually. In that case, you would omit cascade options (which is your current code), and save and update the parts of the object graph manually in the order that does not break any integrity constraints.
While involving some boilerplate code, manual approach gives you flexibility in more complex or performance-demanding situations, like when you don't want to load or reinitialize the parts of the detached graph for which you know that they are not changed in some context in which you save it.
For example, let's assume a case where there are separate web service methods for updating account, contact and asset. In the case of the account method, with cascading options you would need to load the entire account graph just to merge the changes on the account itself, although contact and asset are not changed (or worse, depending on how you do it, you may here revert changes on them made by somebody else in their dedicated methods in the meantime if you just use the detached instances contained in the account).
Regarding auto-generated ids, you don't have to specify them yourself, just take them from the saved entities (Hibernate will set it there). It is important to take the result of the repository's save method if you plan to use the updated entity afterwards, because merge operation always returns the merged copy of the passed-in instance, and if there are any newly persisted associated entity instances in the updated detached graph, their ids will be set in the copy, and the original instances are not modified.
I have 2 entities in my DB with one-to-one one directional mapping:
User and PasswordResetToken. The idea behind this is to create new token each time user requests password reset and store only the latest one.
Below are my entities:
#Entity
#Table(name = "USERS")
#Getter #Setter
public class User implements Serializable {
#Id
#Column(name = "ID")
#GeneratedValue(strategy = GenerationType.AUTO, generator = "usersSeq")
#SequenceGenerator(name = "usersSeq", sequenceName = "SEQ_USERS", allocationSize = 1)
private long id;
#Column(name = "NAME")
private String name;
#Column(name = "PASSWORD")
private String password;
#Column(name = "EMAIL")
private String email;
#Column(name = "ROLE")
private Integer role;
}
///...
#Entity
#Table(name = "PASSWORD_RESET_TOKENS")
#Getter
#Setter
public class PasswordResetToken implements Serializable {
private static final int EXPIRATION = 24;
#Column(name = "TOKEN")
private String token;
#Id
#OneToOne(fetch = FetchType.EAGER, cascade = CascadeType.ALL)
#JoinColumn(nullable = false, name = "user_id")
private User user;
#Column(name = "EXPIRY_DATE")
private Instant expiryDate;
public PasswordResetToken() {
}
public void setExpiryDate(ZonedDateTime expiryDate) {
this.expiryDate = expiryDate.plus(EXPIRATION, ChronoUnit.HOURS).toInstant();
}
}
Also, I have DTOs created for both of them to pass them around my app.
Code snippets:
#Getter #Setter
public class PasswordResetTokenModel {
private String token;
private ZonedDateTime expiryDate;
private UserModel user;
}
UserModel is also used for Spring Security
#Getter
#Setter
public class UserModel extends User {
public UserModel(String username, String password, Collection<? extends GrantedAuthority> authorities) {
super(username, password, authorities);
}
private long id;
private String name;
public String getEmail() {
return this.getUsername();
}
}
For population I've created 2 populators:
#Component
public class UserPopulatorImpl implements UserPopulator {
#Autowired
UserDetailsService userDetailsService;
#Override
public UserModel populateToDTO(User user) {
UserModel userModel = new UserModel(user.getEmail(), user.getPassword(), userDetailsService.getAuthorities(user.getRole()));
userModel.setId(user.getId());
return userModel;
}
#Override
public User populateToDAO(UserModel userModel) {
User user = new User();
user.setEmail(userModel.getEmail());
user.setName(userModel.getName());
user.setPassword(userModel.getPassword());
//TODO: change it!
user.setRole(1);
return user;
}
}
//...
#Component
public class PasswordResetTokenPopulatorImpl implements PasswordResetTokenPopulator {
#Autowired
UserPopulator userPopulator;
#Override
public PasswordResetTokenModel populateToDTO(PasswordResetToken passwordResetToken) {
PasswordResetTokenModel passwordResetTokenModel = new PasswordResetTokenModel();
passwordResetTokenModel.setUser(userPopulator.populateToDTO(passwordResetToken.getUser()));
passwordResetTokenModel.setToken(passwordResetToken.getToken());
passwordResetTokenModel.setExpiryDate(ZonedDateTime.ofInstant(passwordResetToken.getExpiryDate(), ZoneId.systemDefault()));
return passwordResetTokenModel;
}
#Override
public PasswordResetToken populateToDAO(PasswordResetTokenModel passwordResetTokenModel) {
PasswordResetToken passwordResetToken = new PasswordResetToken();
passwordResetToken.setExpiryDate(passwordResetTokenModel.getExpiryDate());
passwordResetToken.setUser(userPopulator.populateToDAO(passwordResetTokenModel.getUser()));
passwordResetToken.setToken(passwordResetTokenModel.getToken());
return passwordResetToken;
}
}
I'm saving object using
sessionFactory.getCurrentSession().saveOrUpdate(token);
When I use this code, I'm getting following exception
object references an unsaved transient instance - save the transient instance before flushing: com.demo.megaevents.entities.User
There are currently 2 issues in this code:
Seems like Cascade.ALL in my OneToOne mapping is not working. If
I create separate primary key in Token class everything works almost
as expected but storing every created token in DB (more like
OneToMany relation), however I want to avoid it as I need to store
only one token per user in my DB
I don't like using new in populators, as it forces hibernate to create new object while flushing session. However, I also don't want to do another select to fetch this data from DB because just before mentioned populator I already do this query to fetch it and I think that it's an overhead.
Also, I really want to have DTOs and I don't want to remove DTO layer.
So, my questions:
What is the correct way to handle population between DTO and entities?
Are there any other improvements (probably architectural) to my solution?
Thanks a lot.
I'm not sure why you would let UserModel extend User, but I guess you did that because you didn't want to have to copy all properties from User into UserModel. Too bad, because that's what is going to be needed to have a clean separation between the entity model and data transfer model.
You get that exception because you try to persist a PasswordResetToken that has a reference to a User object with an id, but the User isn't associated with the current session. You don't have to query the user, but at least association it with the session like this:
PasswordResetToken token = // wherever you get that from
Session s = sessionFactory.getCurrentSession();
token.setUser(s.load(User.class, token.getUser().getId());
s.persist(token);
Cascading would cause the User to be created/inserted or updated via a SQL INSERT or UPDATE statement which is apparently not what you want.
You could do the Session.load() call in you populators if you want, but I'd not do that. Actually I would recommend not having populators at all, but instead create the entity objects in your service instead.
Normally you only have a few(mostly 1) ways of actually creating a new entity object, so the full extent of the transformation from DTO to entity will only be relevant in very few cases.
Most of the time you are going to do an update and for that, you should first select the existing entity and apply the fields that are allowed to be changed from the DTO on the entity object.
For providing the presentation layer with DTOs I would recommend using Blaze-Persistence Entity Views to avoid the manual mapping boilerplate and also improve performance of select queries.
I've been working on a project which is now in production mode. Now I've been told to remove the mappings completely from the .hbm.xml files so that I need to handle every relationships manually in the program code. It's really a big problem coz the every DB operation which I've written is in Hibernate Criteria.
Just consider the following Criteria
Criteria criteria = getSession().createCriteria(Table1.class,"table1");
criteria.createAlias("table1.table2", "table2")
.createAlias("table1.table3", "table3")
.createAlias("table3.table4", "table4")
.createAlias("table3.table5", "table5")
.setProjection(Projections.projectionList()
.add(Projections.property("id"),"id")
.add(Projections.property("c1"),"c1")
.add(Projections.property("c2"),"c2")
.add(Projections.property("c3"),"c3")
.add(Projections.property("table2.c1"),"table2.c1")
.add(Projections.property("table2.c2"),"table2.c2")
.add(Projections.property("table3.c1"),"table3.c1")
.add(Projections.property("table5.c1"),"table3.table5.c1"))
.add(Restrictions.eq("table4.c1", Constants.STATUS_ENABLED))
.setResultTransformer(new AliasToBeanNestedResultTransformer(Table1.class));
return criteria.list();
This is the criteria which is written when all the relationships are present in .hbm.xml files. Now you can understand what will be problem I'm going to face when removing the mapping from .hbm.xml files. TBH, I've to rework entire DAO classes by removing Criteria and replacing it with HQL. Also I'll not be able to fetch the result directly as object by using HQL.
Is it possible to only make small changes to the criteria (like defining the join between tables in the criteria itself) so that I'll get the same output even after removing the mappings from .hbm.xml files..?
Yes you can use the Java Persistence Annotations in the Entity classes and will work the same way the .hbm.xml classes do.
Take this for example
#Entity
public class Employee {
#SequenceGenerator(name="EMPLOYEE_SEQ", sequenceName="EMPLOYEE_SEQ", initialValue=1, allocationSize=1)
#Id #GeneratedValue(strategy=GenerationType.AUTO, generator="EMPLOYEE_SEQ")
private int id;
#Column(nullable = false, length = 50)
private String name;
#ManyToOne(targetEntity = Country.class, optional = true, fetch = FetchType.LAZY)
#JoinColumn(name = "loanID", updatable = false, insertable = false)
private Loan loan;
#Column(name = "loanID", updatable = true, insertable = true)
private Integer loanID;
public int getId() {
return id;
}
public void setCompanyID(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Integer getLoanD() {
return loanID;
}
public void getLoanD(Integer loanID) {
this.loanID = loanID;
}
}
And then you just use the criterias like you used to.
I got these 2 entities:
#javax.persistence.Entity
public class Book {
#javax.persistence.EmbeddedId
private BookPK id;
private String title;
#javax.persistence.ManyToOne(fetch = javax.persistence.FetchType.LAZY)
#javax.persistence.JoinColumns({
#javax.persistence.JoinColumn(name = "LNGCOD", referencedColumnName = "LNGCOD"),
#javax.persistence.JoinColumn(name = "LIBCOD", referencedColumnName = "LIBCOD") })
private Language language;
}
#javax.persistence.Entity
public class Language {
#javax.persistence.EmbeddedId
private LanguagePK id;
private String name;
}
with composed PK's:
#Embeddable
public class BookPK implements Serializable {
private Integer bookcod;
private Integer libcod;
}
#Embeddable
public class LanguagePK implements Serializable {
private Integer lngcod;
private Integer libcod;
}
If I try to create a new Book and persist it, I get an exception telling me libcod is found twice in the insert statement ("Column 'libcod' specified twice"). But I can't use "insertable = false" when defining the JoinColumn ("Mixing insertable and non insertable columns in a property is not allowed").
Is there any way to define these objects + relationship so the columns are managed automatically by Hibernate ?
Hibernate and JPA automatically make persistent all the modifications made to persistent entities while they are attached to the session. That's the whole point of an ORM: you load a persistent object, modify it, and the new state is automatically persisted at the commit of the transaction, without any need to call persist, merge, save or any other method.
Note that calling persist on a persistent entities (except for its cascading side-effects) makes no sense. persist is to make a transient entity (i.e. a new one, not in the database yet, with no generated ID) persistent.
You can only have one mutator for the libcod. Probably, what you should do is leave the libcod getter in the BookPK class, and in the Language class, use a joincolumn reference with a ref back to the libcod. It works fine for single embedded PK classes, but for multiple PK classes, you may have to play around.
So, in your Language class, you would have this.
#javax.persistence.Entity public class Language {
private LanguagePK id;
private Integer libcod;
#javax.persistence.EmbeddedId #AttributeOverrides({
#AttributeOverride(name = "lngcod", column = #Column(name = "LNGCOD", nullable = false)),
#AttributeOverride(name = "libcod", column = #Column(name = "LIBCOD", nullable = false)) })
public LanguagePK getId() {
return this.id;
}
public void setId(LanguagePK id) {
this.id = id;
}
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "LIBCOD", insertable = false , updatable = false)
public Integer getLibcod() {
return this.libcod;
}