I need help in modeling a set of tables/classes in my project. I also need help on how to do the hibernate mapping for these tables. I have following tables in my project.
Person
Organization
Contact
Address
Person table can have one or more addresses. Organization and Contact can have only one Address. So I have added the following columns to establish the relationship between the tables.
Address table has PersonId [Since one Person can have more than one address].
Organization and Contact table has AddressId [Since these tables can have only one address].
I want to know what java classes I need to create for these tables. Currently I have Person, Address, Organization and Contact classes. Not sure how to link Address class to Person, Organization and Contact class.
I want to know whether I should consider Address as a Component or an Entity. And how create the xml mapping Address is considered as a Component.
The PersonId in Address table may have null values for the Address records created for Organization and Contact. I fine with creating a separate table [say Person_Address] to store list of addresses for a person. But having this link table might give an provision for many to many relationship between Person and Address tables. How do I enforce one to many relationship in this case.
I would go for what you suggest in 3.
By using a OneToMany relationship on the set of addresses in the Person class the intermediate table will be created automatically and I guess it will have a unique constraint on the address id.
Edit: You will only get a reference in the address table if you add a corresponding many-to-one annotation in the address class and use the and map the one-to-many annotation to that field. But since your not doing that you'll get a Person_Address table even with a one-to-many relationship without creating any extra classes.
You should model your classes like you would in plain java. I.e Person would have a set of addresses, the others will have just one and the Address class is oblivious of the others.
Then you add a #OneToMany annotation in the Person class and #OneToOne class in the others. Or you put that in your orm.xml, although annotations is much better for maintenance.
As for Component/Embedable vs Entity I would suggest entity as it is the simplest and no limitations. Don't use to many concepts at once, and stick to the main road.
Related
I am trying to build a Book app.
The entities are so-
The Entity User has a field called Role which specifies if this is an Author or Reviewer. Currently, I am using an Enum data member to differentiate if the User is an Author or Reviewer. One single instance of a User cannot be both.
A Book will have 1...* Authors- So a User entity which is an Author will have a many-to-many relation with entity Book
A Book will have 1...* Reviewers- So a User entity which is a Reviewer will have a many-to-many relation with entity Book
I was wondering how would I implement the User side - I preferably want one single collection of Books- If the User is an Author, this will contain a reference to the books he has authored. If it is a reviewer, it will contain references to the books on which he is a reviewer.
I am wondering if there is any construct in JPA/ Hibernate which can enable this.
I could always implement Author and Reviewer as different entities, but I still want to know the answer to such a situation which I presume must be quite commonly encountered.
Here's my problem : i have two databases, with one containing tables that i will need in the second one. These tables are lists for many-to-one relationships, so they won't be updated frequently, but it's still a possibility.
So in order to not duplicate my tables i wanted to use a foreign data wrapper, create foreign tables that map them, and then create views that map these foreign tables. I want these views because i need to set specific privileges depending on the role of the user (something you can't do with foreign tables right ? You can only set an owner ?)
Anyway, now i have my views, and now i created Java classes so that Hibernate can map the tables.
My questions :
1/ Is it bad practice to use #Id #JoinColumn on classes that are mapping views ? Because they don't have primary or foreign keys. Will it end in lack of performances ?
2/ Am i completly missing something, and maybe there is another database design that could solve my problem ? Knowing that i can't merge my two datables and create two separate schemas.
Thanks in advance !
Like in a topic. How to decide which entity should be the owner of relation. I have two entity and want to create mantToMany relation between. I hvae class teams and persons. One person can be in many teams, and many teams can have many person. But my question is how to decide in which entity should i create #jointable.
I need to define new table related to predefined 'User' table.
Please, help me to write a correct JDL code for this
entity diagram
I tried to write file "mytable.jh" and import :>jhipster import-jdl mytable.jh
entity MyTable{
userid Long, //relation to table jhi_user
}
relationship OneToMany {
User{id} to Mytable{userid}
}
and got
{ name: 'IllegalAssociationException',
message: 'Relationships from User entity is not supported in the declaration between User and Mytable.',
prototype:
Error
Basically you can't add new fields to the jhi_user table, and JDL won't let you do anything that would cause that to happen.
You can add a User object reference to another entity with something like
relationship ManyToOne {
Mytable{userid} to User
}
Note there that I am not putting {anything} after User -- this means the User has no idea which Mytable it's associated with. If you want to "back up" from an instance of Mytable to an instance of User, you have to search from the Mytable side; the User won't have any fields or getters/setters related to an instance of Mytable.
Also note that the userid field is not necessarily strictly for relating the two entities. The JDL and code generation actually takes care of creating the relationships and primary/foreign keys for you. So
entity Car {
}
relationship ManyToOne {
Car{user} to User
}
means for every User, there are many Cars, or another way of saying it is for every Car there is one user whose field name within the Car object will be user. So you'll have Car.getUser() method, etc.
When you define a field within an entity block, you're defining a property of that entity, not a relation -- that property is independent of all other objects in your model.
You still won't have a User.getCars() method though. This is not possible with current jHipster design.
I think this tip in the jhipster doc might help you, I never looked at it, but a mate did this during my project I'm crrently working on. Hope this helps. You can always ask Paul-Etienne for further information, he will gladly help.
I am going to use ElasticSearch for as the search repository in my application.
I have a few questions regarding what is best practice when it comes to organizing
objects in the search index when the objects have associations/relations to each other.
From what I know search indexes is a flat structure and doesn't work with the concept of
relations in the same way as a database.
Let say you have these domain objects:
Person:
- Has a one-to-many relationship with Car
Car:
- Is owned by one Person, many-to-one with Person
Department:
- Each Department have many People and each Person may belong to many Department, many-to-many
What would be the best way to store this in the search index? What are the options? For instance I want to find all the people belonging to a certain deparment, or all people where the car has more than 300 bhp.
I am using the Java client API if it matters.
Elastic search (or Lucene) isn't a relational database, so you would need to flatten your relationship model.
Try to model a view that gets this structure -
Car|Person|Department
This will give you all attributes required to lookup a car. This can be imported into a document for Car.
Similarly
Person|Department
will give you all information for a person. This will help you lookup a Person
Department can be a third document.
You can have multiple documents for each entity. But the relationship needs to be translated as a property of the entity.