We Keep Coding

Persist non-primitive data in JPA

I am creating a program that needs to interact with a database. It's a bare-bones inventory management system, so the entities are 'Item' and 'Patron'.
Edit: This is a Vaadin application using Spring boot and spring data JPA
First I will start with my 2 classes and omit getters/setters for brevity.
#Table(name="item")
#Entity
public class Item implements Serializable, Cloneable {
#Id
#GeneratedValue(strategy=GenerationType.AUTO)
private long barcode;
#NotNull
private String name, type;
#NotNull
private boolean isAvailable;
#Nullable
private boolean isLate;
#Nullable
private String notes;
#Nullable
private Patron currentPatron;
#Nullable
private Patron[] history;
#Nullable
private Date checkOutDate, dueDate;
public Item() {}
public Item(long barcode, String name, String type, boolean isAvailable) {
this.barcode = barcode;
this.name = name;
this.type = type;
this.isAvailable = isAvailable;
}
public Item(long barcode, String name, String type, String notes, boolean isAvailable) {
this.barcode = barcode;
this.name = name;
this.type = type;
this.notes = notes;
this.isAvailable = isAvailable;
}
public Item(long barcode, String name, String type, String notes, boolean isAvailable, Date checkOutDate, Date dueDate, boolean isLate, Patron currentPatron, Patron[] history) {
this.barcode = barcode;
this.name = name;
this.type = type;
this.notes = notes;
this.isAvailable = isAvailable;
this.checkOutDate = checkOutDate;
this.dueDate = dueDate;
this.isLate = isLate;
this.currentPatron = currentPatron;
this.history = history;
}
}
#Entity
#Table(name="patron")
public class Patron {
#Id
private long id;
#NotNull
private String name, email;
#Nullable
private Item[] checkedOutItems;
#Nullable
private List<Item> itemHistory;
#Nullable
private boolean owesFines;
#Nullable
private int finesOwed;
public Patron() {}
public Patron(long id, String name, String email, boolean owesFines) {
this.id = id;
this.name = name;
this.email = email;
this.owesFines = owesFines;
}
public Patron(long id, String name, String email, Item[] checkedOutItems, List<Item> itemHistory, boolean owesFines, int finesOwed) {
this.id = id;
this.name = name;
this.email = email;
this.checkedOutItems = checkedOutItems;
this.itemHistory = itemHistory;
this.owesFines = owesFines;
this.finesOwed = finesOwed;
}
In practice the Patron Object is instantiated by scanning their campus ID with a MSR. Then that data populates the name, email and ID fields of the patron class.
When checking out an item, the patron would first swipe their card with the MSR (the system would confirm they are in the DB, add them if not).
After their magnetic strip is scanned, the QR code for the item they want is scanned so we can tie that item to them.
When an item is checked out to a patron, we need to get their id, name and email from the Patron table and then populate the rest of its variables: check_out_date, due_date, etc.
A patron can check out many items, but only one item can be checked out to a patron. Does This establish a OneToMany relationship? Patron -> Item(
My thought process was as follows:
For Patron Objects
have an array of Items to store the barcode of the items they currently have.
have an arraylist of items to store info about what patron had it and when List<Item> history, that way the code is as simple as history.addToFront(something)
For Item Objects
have a Patron object to see who has it
have an arraylist of patrons to see all the times it was checked out
Q1: Is it redundant to have an array and a list as instance data for both classes?
Q1.2: Are an array of objects and a list of objects even appropriate data structures for a scenario like this?
Q1.3: Is there a difference in using javax.persistence.*; and org.springframework.data.annotation.*; for something like ID and is there a difference between import javax.validation.constraints.NotNull; and import org.springframework.lang.NonNull;
Q2: Does this produce a OneToMany relationship between Patron and Items?
Q3: In order to achieve this, I believe I need some additional tables in my database. I was thinking something like this: (And I realize I will need to include the appropriate spring annotations when implementing the new schema)
Item table
create table item(barcode int(10) primary key, name varchar(64) not null, type varchar(64) not null, availability boolean, is_late boolean, note varchar(255), check_out_date Datetime, due_date Datetime); #foreign keys for currentPatron and Patron History
Patron table
create table patron(id int(10) primary key, name varchar(64) not null, email varchar(64) not null, owes_fines boolean, fines_owed int); #foreign key to item table?
Patron_Item_History table
: This would pull id, name, email from the patron table, and then id, check_out_date, due_date from the item table?
Item_Patron_History table: Similar structure to the above table?
Thank you in advance.

OK here goes,
I am assuming you're building you application with Spring Boot, Hibernate as your ORM and probably some kind or relational database (MySQL).
Regarding db design:
Yes the Patreon object here is the owning entity with a OneToMany relation to the Item entity (since one Patreon may have N objects).
Your Patreon entity could do with the following redesing:
1) Try to use non-primitive types especially for table keys (long id -> Long id).
2) Lose the array of checkedOutItems as well as the itemHistory list. First of all relations should be modelled using collections and not arrays. Secondly you don't need those two.
You'll never store the checkedOutItems nor the itemHistory this way. Instead create a List<Item> items that will store the Patreon items while describing the relation (here are some examples: http://www.baeldung.com/hibernate-one-to-many)
3) Again with the Item entity you need to lose the array of history. The only thing you need there is a reference to the owning entity (Patreon in this case) thus completing the ManyToOne side of the relation.
4) Note that Date fields should be annotated with #Temporal also providing the correct type (you can read up for more).
5) Item class in general should do with a redesign.
5) After all the above are in place and assuming you're using Spring, you can create a Repository with which you can query a Patreon object thus retrieving an object along with it's related entities (Items).
Regarding your questions:
Q1: Yes it see. See above for more.
Q1.2: No arrays are not. Lists or better yet Sets are more suited.
Q1.3: Yes there is. The first one a JPA annotation used in relational
databases while the second one is Spring Data specific annotation
used by databases and frameworks that are not of this type
(relational) or do not have a standard persistence API defined (like
JPA). For the NonNull and NotNull are roughly the same with the first
one actually supersetting the latter one (something that is done
often). The only difference I see is the target. You can read for
more here:
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/lang/NonNull.html
https://docs.oracle.com/javaee/7/api/javax/validation/constraints/NotNull.html
Q2: Yes there is. See above.
Q3: With a bit of clever desing I do not see the need for more, but
hey If you feel it'll help you, why not. Just don't overkill the
desingn and it's complexity

I spent a long time yesterday just thinking about a solution in my head.
I made the changes you mentioned to both classes. Long is an object and long is a primitive, you can serialize Long, is that why you recommended I use it instead?
I went on fiddle to test out my thoughts and here's what I came up with. It works as I want it to, but I would then need to implement it in my repository.. Something like repo.checkout(item, patron) should suffice? As for everything else, like populating a list for the client to view, is mainly java logic from here on out?
Anyway, Here's my solution!
create table item (
barcode bigint not null auto_increment primary key,
name varchar(20) not null,
type varchar(20) not null,
is_available boolean not null,
is_late boolean null,
notes varchar(255) null,
check_out_date datetime null,
due_date datetime null
#create index idx_barcode (barcode));
create table patron (
trinity_id bigint not null primary key,
name varchar(30) not null,
email varchar(20) not null,
owes_fines boolean not null,
fines_owed int null
#create index idx_trinity_id (trinity_id));
create table checked_out_items (
ref_id bigint primary key auto_increment not null,
patron_id bigint not null,
item_id bigint not null,
item_available boolean not null,
item_check_out_date datetime null,
item_due_date datetime null);
alter table checked_out_items
add constraint fk_patron_id
foreign key (patron_id) references patron(trinity_id),
add constraint fk_item_id
foreign key (item_id) references item(barcode)
#add constraint fk_item_available
#add constraint fk_check_out_date
#add constraint fk_due_date
#foreign key (item_available references item(is_available)
#foreign key (item_check_out_date) references item(check_out_date)
#foreign key (item_due_date) references item(due_date)
on update cascade
on delete cascade;
insert into patron values(0000000,'Test Erino','test#erino.edu',0,null);
insert into item values(1,'Chromebook','Laptop',0,null,null,null,null);
insert into checked_out_items(patron_id,item_id,item_available,item_check_out_date,item_due_date)
select patron.trinity_id,item.barcode,item.is_available,item.check_out_date,item.due_date
from patron
inner join item;
and lastly:
select * from item;
select * from patron;
select * from checked_out_items;

Entity retrieved from database with same case as in query

My database contains the following table:
table:
country {
code varchar(255) not null
primary key
};
class:
#Entity
public class Country {
#Id
#Column(name = "code")
private String mCode;
public String getCode() {
return mCode;
}
public void setCode(String code) {
mCode = code;
}
}
sample table rows:
| code |
|------|
| USA |
| UK |
When I retrieve a country using the following CrudRepository:
public interface CountryRepository extends CrudRepository<Country, String> {
}
First scenario:
mRepository.findOne("USA")
It will give me the following result in my rest api:
{
"code": "USA"
}
Second scenario:
mRepository.findOne("UsA")
It will give me the following result in my rest api:
{
"code": "UsA"
}
Third scenario:
mRepository.findOne("Usa")
It will give me the following result in my rest api:
{
"code": "Usa"
}
I have also inspected the same behavior using the debugger and found my object in memory actually have the same behavior.
What I Want: I want the returned data to be the same case as in database.

As already hinted by #Bedla in the comment, you may be using a case insensitive varchar data type in your database. However, this is not recommended for primary keys in Hibernate (and in general), because Hibernate relies on id property value uniqueness when referring to entities in the persistence context (and second-level cache if enabled).
For example, after loading an entity by "USA" and then by "usa" (or after merging a detached "usa" while "USA" has already been loaded, etc) in the same persistence context you may end up with two different instances in the persistence context, meaning further that they would be flushed separately thus overwriting each other changes, etc.
Rather use a case sensitive data type in the database, but allow searching by ignoring case:
public interface CountryRepository extends CrudRepository<Country, String> {
#Query("select c from Country c where upper(c.mCode) = upper(?1)")
Country getCountry(String code);
}
PS Country codes are not good candidates for primary keys in general, because they can change.

Try overriding the equals() and hashcode() methods in your entity such that they take the case of mCase into consideration (and don't use any other fields in these two methods).

you could wrap the CrudRepository with another layer such as service or controller.
public Country findOne(String code){
Country country = mRepository.findOne(keyWord)
if (country !=null){
country.setCode(code)
return country;
}
return null;
}
The entity returned from mRepository is what stored in database. I think you should have another method to do this special handling.

By calling repository.findOne("Usa") (default implementation is SimpleJpaRepository.findOne) Hibernate will use EntityManager.find which instantiates the entity(if it's found in the Database and not present in first and second level cache) and set the passed argument value as primary key, using SessionImpl.instantiate method, instead of using the Select query result.
I've filled a ticket in Hibernate Jira for this issue.
Solution 1: Do not use natural id as a primary key:
As said, it's not recommended to use a business/natural key as primary key, as it may change in the future as business rules change (Business rules can change without permission!!) + If you're using clustered index, a string may be slower for primary key, and perhaps you will find two rows in the database: Country('USA'), Country('USA '), use a Surrogate Key instead, you can check this two SO questions for more details:
What's the best practice for primary keys in tables?
Strings as Primary Keys in SQL Database
If you choose this option don't forget to map a unique constraint for the business key using #UniqueConstraint:
#Entity
#Table(uniqueConstraints = #UniqueConstraint(columnNames = "code"))
public class Country {
// Your code ...
#Column(name = "code", nullable=false)
private String mCode;
//...
}
Solution 2: Change Country.mCode case:
If you have a possibility to store all Country.code in UpperCase :
#Entity
public class Country {
private String mCode;
protected Country(){
}
public Country(String code){
this.mCode = code.toUpperCase()
}
#Id
#Column(name = "code")
public String getCode() {
return this.mCode;
}
// Hibernate will always use this setter to assign mCode value
private void setCode(String code) {
this.mCode = code.toUpperCase();
}
}
Solution 3: Customize the CrudRepository:
While adding a custom function to your repository, you should always get rid of the default findOne(String), so you force others to use the "safest" method.
Solution 3.1:
Use custom implementations for mRepository find method (I named it findOneWithRightStringCase):
public interface CountryRepositoryCustom {
Country findOneWithRightStringCase(String id);
}
public class CountryRepositoryImpl implements CountryRepositoryCustom{
#PersistenceContext private EntityManager entityManager;
#Override
public Country findOneRespectCase(String id) {
try {
return entityManager.createQuery("SELECT c FROM Country c WHERE c.mCode=:code", Country.class).setParameter("code", id).getSingleResult();
} catch (NoResultException ex) {
return null;
}
}
}
public interface CountryRepository extends CrudRepository<Country, String>, CountryRepositoryCustom {
#Override
public default Country findOne(String id) {
throw new UnsupportedOperationException("[findOne(String)] may not match the case stored in database for [Country.code] value, use findOneRespectCase(String) instead!");
}
}
Solution 3.2:
You may add a Query methods for your repository :
public interface CountryRepository extends CrudRepository<Country, String> {
Country findByMCode(String mCode);
#Override
public default Country findOne(String id) {
throw new UnsupportedOperationException("[findOne(String)] may not match the case stored in database for [Country.code] value, use findByMCode(String) instead!");
}
}
Or Use #Query(JPQL):
public interface CountryRepository extends CrudRepository<Country, String> {
#Query("select c from Country c where c.mCode= ?1")
Country selectCountryByCode(String mCode);
#Override
public default Country findOne(String id) {
throw new UnsupportedOperationException("[findOne(String)] may not match the case stored in database for [Country.code] value, use selectCountryByCode(String) instead!");
}
}
Hope it helps!
Note: I'm using Spring Data 1.11.8.RELEASE and Hibernate 5.2.10.Final.

How to return an entity by property if it already exists?

#Entity
public class Language {
#Id
#GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
#Column(length = 2)
private String code; //EN, DE, US
public Language(String code) {
this.code = code;
}
}
#Entity
public class ProductText {
#OneToOne(Cascade.ALL)
private Language lang;
}
ProductText text = new ProductText();
text.setLang(new Language("en")); //what if "en" exists?
dao.save(text);
Now, when I persist the ProductText, everytime a new Language object would be generated.
Can I prevent this, and in case a language table entry with code = 'en' exists this existing entity should be linked instead.
My initial goal is to not having to repeat the countryCodeString "EN" multiple times in my product-text table, but just reference the id. But does this really make sense? Should I rather just use the plain String without an extra table? (I later want to query a list of productTexts where lang = 'de').
Is the only change executing a select like dao.findByLang("en") before?
Or is there also some hibernate feature that would support this without explicit executing a query myself?

Do you process the value "en" further or do you display it directly? If only used for displaying purposes, I would just store the string, but if you want to reduce redundancy by using foreign key IDs you have to create an Entity containing the language string en which can be persisted via entity manager and which you have to obtain out of the entity manager before persisting to reuse it.

If there is only three different possible values for the language, you can also use an enum like this :
public enum Language {
EN("EN"),
DE("DE"),
US("US");
private String code; //EN, DE, US
public Language(String code) {
this.code = code;
}
// Getter...
}
#Entity
public class ProductText {
#Enumerated(EnumType.STRING)
// Or #Enumerated(EnumType.ORDINAL)
private Language lang;
}
EnumType.STRING will store the enum in the database as a String, while EnumType.ORDINAL will store it as an int. Int is maybe a little more efficient, but the mapping could change if you insert a new value in your enum. String is more flexible since it will use the names of your enum members.
In both case, you don't have to manage a separate entity and hibernate will not create an additional table, and it's more type-safe than using a plain string.

If the only value in Language is a 2 or 3 letter string, why not just have the string as a member? This will be quicker and more efficient.

How to get a unique key for two fields with Hibernate?

I have two fields of an entity class which I don't want to be unique but to instead be used as composite fields for a key which must itself be unique. For example I have two fields (name and version) which can be the same for other records but together they must be unique. What is the best way to do that using Hibernate (with annotations)? I am using Hibernate Validator for other fields but I am not sure of a way to use that to validate that two fields together compose a unique key. I am using a generic entity class which has an id generic type which can be swapped out for a composite key class but I have yet to get that to work very well.

This will create a unique key on the database:
#Table( name = "MYTABLE",
uniqueConstraints = { #UniqueConstraint( columnNames = { "NAME", "VERSION" } ) } )
This will be enforced by the database on a update or persist.
You'd need to write your own custom validator if you wanted to enforce this using Hibernate Validator.

We usually will wrap the two fields in an inner key class which is marked as #Embeddable. For example:
#Entity
public class Foo {
#EmbeddedId()
private Key key;
...
#Embeddable
public static class Key {
#Column(nullable=false)
private String name;
#Column(nullable=false)
private int version;
protected Key () {
// for hibernate
}
public Key (String name, int version) {
this.name = name;
this.version = version;
}
...
// You probably want .equals and .hashcode methods
}
}

Persisting a list of elements with composite keys

I'm using java persistence to save a list of entities that are associated to another entity. Here's a quick rundown of where I'm having some problems.
#Entity public class Offer implements Serializable {
#Id private Long offerId;
#OneToMany
#Column List<OfferCategory> offerCategories;
}
#Entity public class OfferCategory implements Serializable {
#Embeddable public static class Id implements Serializable
{
#Column(name="offer_id")
private Long offerId;
#Column(name="category_id")
private Long categoryId;
public Id() {}
public Id(Long offerId, Long categoryId) {
this.offerId = offerId;
this.categoryId = categoryId;
}
public boolean equals(Object o) {
if(o != null && o instanceof Id) {
Id other = (Id) o;
return this.offerId.equals(other.offerId) &&
this.categoryId.equals(other.categoryId);
}
else
return false;
}
public int hashCode() {
return offerId.hashCode() + categoryId.hashCode();
}
}
#EmbeddedId private Id id = new Id();
}
Essentially, due to an architecture I cannot change, I need to save a list of Categories as being assigned to an Offer.
Right now, I'm getting a list of Categories from the user and then putting them into the offerCategories field of Offer. However, this doesn't work for new Offers, because there's no way for me to set the ID of a new item.
I'm new to JPA and Seam, so if someone could give me a nudge in the right direction it would be greatly appreciated.

I have not tried using a composite ID before, but one thing to note is that #Column is only used to change the properties of the database column the field is using. It doesn't stipulate a relation, so you still need something like this:
#OneToMany
List<OfferCategory> offerCategories;

As I looked into tutorial I found this:
You cannot use an IdentifierGenerator to generate composite keys. Instead the application must assign its own identifiers.
So you have to assign the id by yourself. Maybe you can make a DB sequence and fetch its values with native query?
And one remark - if you want to use List mapping (order of Categories in Offer is defined by database), you need an index column to contain the index in list. If the order of categories is not important, Set would be more convenient.

Well, my solution for now is that I persist each one (creating keys for new entries), then stuff them into a list, then stuff them into their container object, then persist that object.