I am trying to use an inner class as embeddable to represent some complicated properties of the outer class. When I store this, there is no information from the inner class in the database schema generated by eclipselink.
Does what I'm trying to do seem like a good idea? Why doesn't eclipselink seem to recognize them #Basic attribute on the getRate() in Attributes?
Some other info: Measure must be instantiated using a factory which is provided to the constructor of Person, so I don't even know how I'm going to be able to use this at all. It seems more and more likely that I'll have to make a separate class just to store the state of Person in simple terms (like doubles, not Measures) and use those to create the real Person-type objects, but that has very sad implications for the rest of my application.
#Entity
public static class Person {
#Id
#GeneratedValue(strategy = GenerationType.AUTO)
private int id;
#Transient
public Measure<Double, CleanupRate> rate;
#Embedded
private Attributes attributes;
#Embeddable
public static class Attributes {
#Transient
private Person person;
public Attributes() {
}
public Attributes(Person person) {
this.person = person;
}
#Basic
public double getRate() {
return person.rate.getInternalValue();
}
public void setRate(double value) {
person.rate.setInternalValue(value);
}
}
public Person() {
rate = udm.getMeasureFactory().createMeasure(0.0, CleanupRate.class);
attributes = new Attributes(this);
}
public void setRate(double rate) {
this.rate.setValue(rate);
}
}
Edit:
In order to inject the measure dependency into my objects when they are retrieved from storage, I've added an interface which injects the dependency and used it in my DAO. Since the DAO can be injected, I can propagate the dependency down to the retrieved objects. I got the idea from a blog.
private <T extends UomInjectable> List<T> //
getListOfUomInjectableType(final Class<T> klass) {
List<T> result = getListOfType(klass);
for (UomInjectable injectable : result) {
injectable.injectUomFactory(udm);
}
return result;
}
It is using the access type from the Person class, which is set to field, and so not seeing the annotation at the property level.
You will need to change the access type using Access(PROPERTY) on the embeddable class, and should remove the #Transient annotation on the person attribute.
I think in general you're going to be in trouble having Entities (Embeddable or otherwise) that need constructors with arguments. I'm not sure how that might be related to your schema generation issue, but I think this will be a problem trying to persist/retrieve these objects.
As you hinted, JPA requires all entity types to have a no-argument constructor. While your Attributes class has one, it leaves the 'person' field as null which will fairly quickly result in NPE's. Same with the Person constructor (maybe you left out the one that passes in 'udm' from the sample code?).
The set the Person for the Attributes, just use property access in Person and set it in your setAttributes method.
See,
http://en.wikibooks.org/wiki/Java_Persistence/Embeddables#Relationships
Related
Given the following classes and interface I am wondering how JPa handles it:
public interface Operator{
public String getOperator();
}
Let's stay I then have two implementations of this class:
public class PlusOperation implements Operator, Serializable {
public String getOperator(){
return "+";
}
}
And:
public class MinusOperation implements Operator, Serializable {
public String getOperator(){
return "-";
}
}
There exists a class marked as #Entity which has a property Operator:
#Entity
public class Function {
#Id #GeneratedValue
private Long id;
private Operator operator;
// Other methods & properties omitted for clarity
}
In the Function class therefore, it could hold either a PlusOperation or MinusOperation and neither of these classes have been annotated with #Entity as they don't have any properties that require persisting but they each are different. How does JPA handle this? When persisting a Function object does it automatically (and 'behind the scenes') mark the operator property with the correct Operation implementation?
Just add a JPA AttributeConverter that stores the "operator" field as a String or Integer. That way it doesn't matter one iota whether this other type (which isn't an Entity) doesn't have any properties of its own. You converter is then responsible for deciding what is persisted, and how it is retrieved.
I have an abstract class Entity and then multiple instance can extend Entity
like
A extends Entity {
}
B extends Entity {
}
Now all the entity needs to have entityId
So should I have entityId as a private field in Entity and set it via the constructor, or as a protected member in Entity, so that the subclasses can access it directly?
First off, you can rename entityId as id as it is obviously the id of the entity. It is a member of Entity.
I will assume that id cannot be changed and as such it should be private, set only once and only in the constructor. The class should have a public getId() method. This way other objects can access it in addition to subclasses.
With this implementation id can't be changed accidentally by subclasses.
You should have entityId as part of entity base type as protected.
From a design perspective, entityID should be part of the entity. So, place it in Entity class and make it protected so that its subclasses can access it.
Use protected, So that all the inherited classes can access it.
If the base class constrctor accepts value for entity id, like follows
class Entity
{
protected int EntityId;
public Entity(int _entityId)
{
EntityId=_entityId;
}
}
Then you can use "super" function to call base class constructor from derived class constructor
class ExtendedEntity extends Entity
{
public ExtendedEntity (int _entityId)
{
super(_entityId); // calling base class constructor
}
}
This is probably the main reason why protected members exist. Basically it's the same as private but with the exception that it appears public to your subclasses and to classes in the same package (if that's a concern, go with private).
Now, that's the general theory for instance variables in an inheritance structure, but as others have pointed out, as this seems to be about an ID field, it's still better to make it private and maybe also final. Then write a public getter method, except if no one should be able to get the ID except from the subclasses, then make it protected.
Make it a private field in Entity and make (protected) accessors (getter/setter) so that subclasses have access to the field via the setter or getter (basic OO principles)
You can also write a specific constructor for the Entity class, taking an id as argument and call this constructor from the extending classes. By doing so, your subclasses are always forced to set an id.
Eg.
public class Entity {
private int id;
public Entity(int id) {
setId(id);
}
protected int getId() {
return id;
}
protected void setId(int id) {
this.id = id;
}
}
public class A extends Entity {
public A(int id) {
super(id);
}
}
The difference between #Entity and #Embeddable annotation when each one is added before class declaration?
the first create class as an entity, second insert column from another table?
the first create class as an table, while second is embedded in another class?
the first sets standard as a class, second define table type
the first create table for that class, second embed something into different class
the first define table property, second create union of two tables
#Entity annotation over a class defines that, it has a distinct separate existence. Thus we can run DB queries, without being dependent on any other class. #Embeddable annotation over a class defines that, it does not have independent existence. Thus we cannot run DB queries, without depending on other class. Here is an example to understand it better:
#Entity
User
-- long id
-- String name
-- String email
#Embedded
-- UserDetails userDetail
#Embeddable
UserDetails
-- Date dateOfBirth
-- String sex
-- String address
-- String maritalStatus
Here you can see without having a User, UserDetails is useless.
Generally, in OOP, we first design the classes and then we design database entities. For some classes (like UserDetails class in the above example), we do not want to have separate tables in DB, where their independent existence is meaningless. In those cases, we mark the class as embeddable.
Typically, embeddable classes share the same table as the Entity in which they are embedded
Entities have an identity and can be queried for. Embeddables have no identity of their own and can only be queried for using the owning entities.
If you open an entity class, you will always find the #Id annotation - it is mandatory. If you open an embeddable class, you will never find an #Id annotation - it is forbidden.
EDIT: It is not entirely correct that embeddables can only be stored as a part of the parent, i.e. in the same table. This is only true for one-to-one relationships. You can have Collections and Maps of embeddable objects in the parent entity and they will be mapped to own collection tables.
An entity class is an ordinary user defined Java class whose instances can be stored in the database.
#Entity
#Table(name="dog")
public class Dog{
#Id
#Column(name = "id")
private int id;
#Embedded
private Animal animal;
public Dog(int id,Animal animal){
this.id=id;
this.animal=animal;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public Animal getAnimal() {
return animal;
}
public void setAnimal(Animal animal) {
this.animal = animal;
}
}
Embeddable classes are user defined persistable classes that function as value types. As with other non entity types, instances of an embeddable class can only be stored in the database as embedded objects, i.e. as part of a containing entity object.
#Embeddable
public class Animal {
#Column(name = "name")
private String name;
#Column(name = "location")
private String location;
public Animal(){
}
public Animal(String name,String location){
this.name=name;
this.location=location;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getLocation() {
return location;
}
public void setLocation(String location) {
this.location = location;
}
}
It is an old topic but I would like to add my answer, which is more from theoretical point of view. In DDD (domain driven design) we usually have Entity and Value Objects. The first ones are identifiable only by a an identity that they have. The second ones are not defined by an identity, which means that if all the components that make that particular objects are the same, than the 2 value objects are the same.
The analogy is that in this case, if we were to apply DDD, the Entity is the class annotated with #Entity and the Value Object is the one with #Embeddable. A demonstration of this is the fact that the embeddable object is added as addditional information to an existing record, which already has its own identity defined externally to the embedded object.
Well #Entity signifies that the entity object has significance all by itself it doesn't require any further association with any other object. Where as #Embeddable object doesn't carry any significance all by itself, it needs association with some other object.
Lets take an example of say i have a Employee Object and it has a collection of Address Object as its member variable. Now when when speak of any address we need to tell whose address it is, which employees address it is. If we just talk about the address it doesn't make any sense. Hope this gives you the difference between the two.
Is it possible to store something like the following using only one table? Right now, what hibernate will do is create two tables, one for Families and one for people. I would like for the familymembers object to be serialized into the column in the database.
#Entity(name = "family")
class Family{
private final List<Person> familyMembers;
}
class Person{
String firstName, lastName;
int age;
}
This is an horrible design and I'm really not recommending it (you should just create another table) but it is possible.
First, you'll need to use a byte[] attribute to hold a serialized version of the list of persons that will be stored in a BLOB in the database. So annotate it's getter with #Lob (I would make the getter and setter private to not expose them). Then, expose "fake" getter and setter to return or set a List<Person> from the byte[]. I'm using SerializationUtils from Commons Lang in the sample below (provide you own helper class if you don't want to import this library) to serialize/deserialize on the fly to/from the byte[]. Don't forget to mark the "fake" getter with #Transcient or Hibernate will try to create a field (and fail because it won't be able to determine the type for a List).
#Entity(name = "family")
class Family implements Serializable {
// ...
private byte[] familyMembersAsByteArray;
public Family() {}
#Lob
#Column(name = "members", length = Integer.MAX_VALUE - 1)
private byte[] getFamilyMembersAsByteArray() { // not exposed
return familyMembersAsByteArray;
}
private void setFamilyMembersAsByteArray((byte[] familyMembersAsByteArray() { // not exposed
this.familyMembersAsByteArray = familyMembersAsByteArray;
}
#Transient
public List<Person> getFamilyMembers() {
return (List<Person>) SerializationUtils.deserialize(familyMembersAsByteArray);
}
public void setParticipants(List familyMembers) {
this.familyMembersAsByteArray = SerializationUtils.serialize((Serializable) familyMembers);
}
}
Don't forget to make the Person class Serializable and to add a real serialVersionUID (I'm just showing a default here):
public class Person implements Serializable {
private static final long serialVersionUID = 1L;
// ...
private String firstName, lastName;
private int age;
}
But, let me insist, this is an horrible design and it will be very fragile (changing Person might require to "migrate" the content of the BLOB to avoid deserialization issues and this will become painful. You should really reconsider this idea and use another table for the Person instead (or I don't get why you use a database).
#Type(type = "serializable")
private List<Person> familyMembers;
if you can't use hibernate annotations try this:
#Lob
private Serializable familyMembers;
public List<Person> getFamilyMembers(){
return (List) familyMembers;
}
public void setFamilyMembers(List<Person> family){
familyMembers = family;
}
Annotate the property with #Column and define the type to be ArrayList, not just List. And make Person implement Serializable.
But you should do this only if your motives are very clear, because this is the correct solution in some very rare cases. As Pascal noted, if you ever have to change Person you'll have headaches.
You can create pseudoproperty (getter and setter) which accepts/returns the serialized form, and annotate the familyMembers with #Transient. This would also need to annotate the getters, not fields, for all other properties.
I am trying to model such situation - there is a cash transfer (I mean a car that carries money), that has required amounts of each currency, and also an actual amount for each currency. And it seems to me pointless to create two separate classes, one for required amount and another for actual amount. So the implementation would look like this:
#Entity
public class CashTransferCurrencyAmount {
// id, version and so on
#Column(length = 3)
private String currencyCode;
#Basic
private BigDecimal amount;
#ManyToOne
private CashTransfer cashTransfer;
}
#Entity
public class CashTransfer {
// id, version and so on
#OneToMany(mappedBy="cashTransfer")
private Set<CashTransferCurrencyAmount> requiredCurrencyAmountSet = new HashSet<CashTransferAmountCurrency>();
#OneToMany(mappedBy="cashTransfer")
private Set<CashTransferCurrencyAmount> actualCurrencyAmountSet = new HashSet<CashTransferAmountCurrency>();
}
But how is a CashTransferCurrencyAmount instance to know to which collection it belongs? I have two ideas:
1 - add a discriminator field to CashTransferCurrencyAmount:
public enum RequestType {
ACTUAL,
REQUIRED
}
#Basic
#Enumerated(EnumType.STRING)
private RequestType requestType;
and add #WHERE annotations to collections in CashTransfer. This is preferable for me.
2 - create two join tables. one for mapping requested amounts and one for mapping actual amounts. I dislike this one as I don't want too many tables in my DB.
Are there any other ways to achieve this? I this approach correct?
And please don't tell me to put both requested and actual amounts in one entity. The real case is more complicated, each CashTransferCurrencyAmount has it's own collections so it can't be solved that way.
EDIT
As for requests for complete story - there used to be two values in CashTransferCurrencyAmount - required (I think it should be 'requested') and actual, but now each amount has it's own collection - how this amount is split into denominations. So I need a collection of amounts, each one having a collection of denominations. The type of CurrencyAmount and CurencyDenomination seems to be the same for requested ones and for actual ones.
Since you want CashTransferCurrencyAmount instance to know which collection it belongs to, I assume you want to have some logic based on that. The way I would model your situation would be using inheritance.
You're saying "it seems to me pointless to create two separate classes", I would however try to convince you that you should. You could use a "Single Table" inheritance type, so that you don't introduce additional tables in your DB, which is what you're trying to accomplish.
My shot would look something like:
#Entity
#Inheritance(strategy = InheritanceType.SINGLE_TABLE)
#DiscriminatorColumn(name = "request_type", discriminatorType = DiscriminatorType.STRING)
public abstract class CashTransferCurrencyAmount {
// id, version and so on
#Column(length = 3)
private String currencyCode;
#Basic
private BigDecimal amount;
#ManyToOne
private CashTransfer cashTransfer;
}
#Entity
#DiscriminatorValue("REQUIRED")
public class CashTransferCurrencyAmountRequired extends CashTransferCurrencyAmount {
// required anount specific stuff here
}
#Entity
#DiscriminatorValue("ACTUAL")
public class CashTransferCurrencyAmountActual extends CashTransferCurrencyAmount {
// actual anount specific stuff here
}
#Entity
public class CashTransfer {
// id, version and so on
#OneToMany(mappedBy="cashTransfer")
private Set requiredCurrencyAmountSet = new HashSet();
//Stackoverflow deleting my generic sets! But it's exactly the same as in your code...
#OneToMany(mappedBy="cashTransfer")
private Set actualCurrencyAmountSet = new HashSet();
}