Java has the transientkeyword. Why does JPA have #Transient instead of simply using the already existing java keyword?
Java's transient keyword is used to denote that a field is not to be serialized, whereas JPA's #Transient annotation is used to indicate that a field is not to be persisted in the database, i.e. their semantics are different.
Because they have different meanings. The #Transient annotation tells the JPA provider to not persist any (non-transient) attribute. The other tells the serialization framework to not serialize an attribute. You might want to have a #Transient property and still serialize it.
As others have said, #Transient is used to mark fields which shouldn't be persisted. Consider this short example:
public enum Gender { MALE, FEMALE, UNKNOWN }
#Entity
public Person {
private Gender g;
private long id;
#Id
#GeneratedValue(strategy=GenerationType.AUTO)
public long getId() { return id; }
public void setId(long id) { this.id = id; }
public Gender getGender() { return g; }
public void setGender(Gender g) { this.g = g; }
#Transient
public boolean isMale() {
return Gender.MALE.equals(g);
}
#Transient
public boolean isFemale() {
return Gender.FEMALE.equals(g);
}
}
When this class is fed to the JPA, it persists the gender and id but doesn't try to persist the helper boolean methods - without #Transient the underlying system would complain that the Entity class Person is missing setMale() and setFemale() methods and thus wouldn't persist Person at all.
Purpose is different:
The transient keyword and #Transient annotation have two different purposes: one deals with serialization and one deals with persistence. As programmers, we often marry these two concepts into one, but this is not accurate in general. Persistence refers to the characteristic of state that outlives the process that created it. Serialization in Java refers to the process of encoding/decoding an object's state as a byte stream.
The transient keyword is a stronger condition than #Transient:
If a field uses the transient keyword, that field will not be serialized when the object is converted to a byte stream. Furthermore, since JPA treats fields marked with the transient keyword as having the #Transient annotation, the field will not be persisted by JPA either.
On the other hand, fields annotated #Transient alone will be converted to a byte stream when the object is serialized, but it will not be persisted by JPA. Therefore, the transient keyword is a stronger condition than the #Transient annotation.
Example
This begs the question: Why would anyone want to serialize a field that is not persisted to the application's database?
The reality is that serialization is used for more than just persistence. In an Enterprise Java application there needs to be a mechanism to exchange objects between distributed components; serialization provides a common communication protocol to handle this. Thus, a field may hold critical information for the purpose of inter-component communication; but that same field may have no value from a persistence perspective.
For example, suppose an optimization algorithm is run on a server, and suppose this algorithm takes several hours to complete. To a client, having the most up-to-date set of solutions is important. So, a client can subscribe to the server and receive periodic updates during the algorithm's execution phase. These updates are provided using the ProgressReport object:
#Entity
public class ProgressReport implements Serializable{
private static final long serialVersionUID = 1L;
#Transient
long estimatedMinutesRemaining;
String statusMessage;
Solution currentBestSolution;
}
The Solution class might look like this:
#Entity
public class Solution implements Serializable{
private static final long serialVersionUID = 1L;
double[][] dataArray;
Properties properties;
}
The server persists each ProgressReport to its database. The server does not care to persist estimatedMinutesRemaining, but the client certainly cares about this information. Therefore, the estimatedMinutesRemaining is annotated using #Transient. When the final Solution is located by the algorithm, it is persisted by JPA directly without using a ProgressReport.
If you just want a field won't get persisted, both transient and #Transient work. But the question is why #Transient since transient already exists.
Because #Transient field will still get serialized!
Suppose you create a entity, doing some CPU-consuming calculation to get a result and this result will not save in database. But you want to sent the entity to other Java applications to use by JMS, then you should use #Transient, not the JavaSE keyword transient. So the receivers running on other VMs can save their time to re-calculate again.
In laymen's terms, if you use the #Transient annotation on an attribute of an entity: this attribute will be singled out and will not be saved to the database. The rest of the attributes of the object within the entity will still be saved.
Im saving the Object to the database using the jpa repository built in save method as so:
userRoleJoinRepository.save(user2);
For Kotlin developers, remember the Java transient keyword becomes the built-in Kotlin #Transient annotation. Therefore, make sure you have the JPA import if you're using JPA #Transient in your entity:
import javax.persistence.Transient
I will try to answer the question of "why".
Imagine a situation where you have a huge database with a lot of columns in a table, and your project/system uses tools to generate entities from database. (Hibernate has those, etc...)
Now, suppose that by your business logic you need a particular field NOT to be persisted. You have to "configure" your entity in a particular way.
While Transient keyword works on an object - as it behaves within a java language, the #Transient only designed to answer the tasks that pertains only to persistence tasks.
Related
When writing documents to Mongodb using Morphia, a structure like this will be written without any problems, and without needing the #Embedded annotation:
#Entity
public class Blog {
#Id
private String id;
private List<Comment> comments;
}
The comments field is happily stored as an array of nested Comment elements (Comment is a plain POJO with no annotations).
However, the Morphia documentation suggests I should be using this:
#Entity
public class Blog {
#Id
private String id;
#Embedded
private List<Comment> comments;
}
But in my tests using the #Embedded annotation doesn't appear to do anything additional over simply writing the structure without the annotation.
So what does the #Embedded annotation actually do? Does it affect the ability to query, or index, or some other function of storage other than simply writing the data?
Serializable is not generally used with Morphia. #Embedded is a bit of an ambiguous item whose original intent seems to have gotten lost. In fact, in my fork which I'm working on making the official 2.0 of Morphia, I've restricted it such that it only applies at the class level. This tells Morphia to map the type but not fail the mapping on a missing #Id annotation. In that branch if you wish to specify a name other than the field name, you'd simply use #Property as you would for any non-embedded types.
I hope this clarifies it a little bit at least.
As a rule of thumb, you should #Embedded for objects that are dependent on the parent object (and therefore have no life outside it), and are not shared between objects.
By default, Morphia uses the field name as the value name in Mongo. This can be overridden by specifying a name on the #Embedded annotation:
#Embedded("blog_comments")
private List<Comment> comments;
Even without #Embedded you can still use java class as field type as long as that class implements java.io.Serializable. However that field will be stored in MongoDB in binary format instead of structured data as shown above.
Sources here and here
A lot of JPA entity demo classes have the following snippets:
#Id
private Long id;
Can anyone see any drawbacks to always marking the id property as final?
#Id
private final Long id;
It seems like we almost always want to do this in order to preserve the entities identity.
Short answer
It makes using the JPA class impossible.
Elaboration
final is a Java keyword, not a framework keyword. Java doesn't care what the contract for a JPA entity is. You cannot declare a final field that is not uninitialized, since, by contract, a final field can be written only once.
Also, it is not true that ID properties are immutable. For starters, they change when an object is serialized - a null ID is replaced by a generated ID. Less trivially, when an entity is deleted from a database, its ID is nullified.
In Hibernate, placing there #Id annotation
before the field declaration itself
#Id
private int id;
and before its getter and setter
#Id
public int getId() { return this.id; }
public int setId(..) { .. }
are two different things. This difference takes effect if there's some processing in getter/setter.
The Q is, is there such an issue for non-key fields-- those without the #Id annotation?
My key fields aren't any processed. However, among the others, I've got some fields that i am validating/changing the values before setting. For those fields, should i put the annotations before their getters-setters?
I didn't hit a brick wall as far as I could observe. however - would like to make sure.
TIA.
Note: saw the useful discussion: Where to put hibernate annotations?.
Well no issue for non-key fields, but personally I prefer fields annotation, expecially if you don't have to do some business logic on entity level: code is cleaner, all db related stuff is at the beginning of the class, you don't have strange issue with equals methods (which always use fields - it happened to me) plus, if you have other methods not strictly related to db handling you have to set them #Transient.
I have a model object that's in fact an enum with fields and getters:
#Entity
public enum Type {
TYPE1, TYPE2, TYPE3, TYPE4;
#Column
private Long id;
#Column
private String name;
...
public String getName() {
return this.name;
}
...
}
It compiles and runs fine. However, if I call a getter method, it returns null (it doesn't load any values stored in the database). Is this the standard behavior? Is there a way to make JPA load them?
I'd say there is some misconception in this aproach:
Entities represent objects that can be stored in the database. In this case, the database (or any other persistent store) defines which instances are available.
Enums represent a fixed set of constants that are defined in source code. Thus the class itself defines which constants are available. In addition, it's generally bad practice to change the values of an enum, i.e. the name or id in your case.
You see that they are two quite different concepts which should be treated differently.
To store enums in entities (where the enum is a field of that entity), you could either use #Enumerated and store the name or ordinal of the enum, or (what we do more often) store one of the fields (we mostly use the id) and provide conversion methods.
If you want to store configurable "constants" in the database you might try and use plain entities for that, make the constructor private (Hibernate and other JPA providers should be able to deal with that) and provide an alternative implementation of the Enum class (you can't use the enum keyword though).
Have you looked into the #Enumerated annotation? I haven't ever tried to use it within an enum itself, however it works quit well binding a class property to an enum.
enum Type{TYPE1, TYPE2}
#Column(name="type")
#Enumerated(EnumType.STRING)
public Type getType(){return type;}
public void setType(Type t){type = t;}
If JPA cannot be made to handle this, you could add a public Type valueOf(long id) method to your enum class which you use as a factory to instantiate enum instances representing the values in your legacy table.
I have some philosophical intuitive feeling that adding fields which doesn't mapped to the DB corrupts entity classes and is a wrong way of solving problems.
But are there any concrete situations where using #Transient fields leads to implicit and hard fixing problems?
For example, is it possible that adding or removing 2nd level cache will break our app when there are #Transient fields in our entities?
Considerable update: after some thinking on #Transient fields it seems to me that #Transient fields just should be used in a proper way.
By 'proper way' I mean that entity always should have same behavior. It means that it's a very error-prone behavior when getters returns null's from time to time depending on #Transient field value. And it means that #Transient fields should always be initialized.
And I see only 2 cases of proper usage:
#Transient fields should be initialized in object's constructor:
#Entity
public class SomeEntity
#Id
private long id;
#Transient
private String transientField;
public SomeEntity () {
transientField = "some string";
}
...
}
#Transient fields can be lazy initialized:
#Entity
public class SomeEntity
#Id
private long id;
#Transient
private String transientField;
public String getTransientField () {
synchronized (lock) {
if (transientField == null) {
transientField = "some string";
}
}
return transientField;
}
...
}
Can anyone coment these 2 cases or describe other cases which I missed?
I am using the Transient annotation in some projects that persist with hibernate as well and didn't have any problems yet.
It is usually used for fields that can be determined by other persistent properties and using a cache should work also, because Javas Serialization mechanisms (caches usually expect the cached objects to be serializable) take the Transient annotation into consideration, too. I think it is preferrable to use transient getter and setter properties that provide the information instead of instance fields whenever possible.