I am working on converting a legacy system to use hibernate (version 3.3.x) instead of using hand crafted SQL. I have run in to some problems mapping my datamodel that pertians to composite keys. I've created a solution I think works, but I am not overly fond of it. Hence, I would like to see how the diagram below could/should be mapped and see if I am on the "right" track.
In the diagram StuffTypes is a pretty static table that don't change (no inserts or updates). Parent is the only table that currently has a DAO class associated to it (the others should be persisted when the parent instance is). Stuff has a StuffType and a number of SubStuff associated with it. Finally, SubStuff is just a many to many mapping table between Stuff and StuffTypes.
What is the best way of mapping these entities to Java objects using annotations?
Personally, I often refer to the section 3.2 Primary Keys through -ToOne Relationships of the JPA Wiki Book. And read also 3.1 Composite Primary Keys.
Adding a primary key stuff_id to the Stuff table and another primary key substuff_id to SubStuff is less complicated. Composite keys are possible, of course. If seen solutions where #Embeddable classes have been introduced to model the composite keys.
Hibernate Reference is your best bet. Try this, Mapping Entities with Composite Keys.
Related
I've seen many examples and real-life projects where database table columns have a unique prefix that corresponds to the table name. Small example:
CREATE TABLE customers (cus_id BIGINT, cus_name VARCHAR(255), cus_adr_id BIGINT);
CREATE TABLE addresses (adr_id BIGINT, adr_postcode CHAR(5));
How can I accomplish this in Hibernate or JPA?
I already tried to implement PhysicalNamingStrategy but that doesn't seem to have access to the entity itself so I have no way to know the entity when setting the column name.
I now hope that there is a better way than placing annotations above every single variable declaration. That's pretty verbose and doesn't fit to my expectations to ORM which in my eyes should ideally provide an automatic way of mapping. Moreover, the ID and other properties that are shared among entities I have to keep in a base-class entity which makes the annotations even more complicated.
I am developing a JavaEE application and I use JPA/Hibernate as a persistence engine. While developing the application, some questions raised to my mind.
The application consists of users and their roles in a N:M relationship. Here is the database subset of the above tables.
I am relatively new to Hibernate and at first I asked IntelliJ IDEA to generate the mapping for me. What it did was generate the following Java classes:
UserEntity.java
RoleEntity.java
UserXRoleEntity.java
UserXRoleEntityPK.java
Thus, it generated a mapping for the relation table and two 1:N relationships, one between user and userXrole and one between role and userXrole.
After some research, I found that, by using the #ManyToMany annotation, I could omit mapping the userXrole table into a Java class and just declare it within the annotation as the #JoinTable.
So the question is:
Why does IntelliJ generate the entities that way?
Is it just a more generic way that helps generation, or does it have any other advantages. Would you argue in favour of one way or the other?
Is it just a more generic way that helps generation, or does it have any other advantages.
JPA doesn't know if a table is just a join table, that's why you have to tell it (using #JoinTable). The generator might guess, but it will probably only generate #ManyToMany if your table names match JPAs defaults.
Would you argue in favour of one way or the other?
I'd use #ManyToMany if i don't have a reason (finer grained control over lazy/eager fetching maybe?) for separate mapping entities, mostly because less code = less errors.
I am trying to create a pojo classes base on some legacy tables which apparently doesn't have a unique key assigned to them (meaning some tables don't even have a primary key or a unique value).
With that being said, which apporach should I take to generate my pojo classes in java? Any suggestions?
As well, which model should I be going for in this case, Hibernate or myBatis?
What if there is one to many relationships? Do I have to manually generate those pojo myself?
You can use Hibernate as ORM tool and apply reverse engineering, ORM tool doesn't bother about constraint.
hibernate reverse engineering on a denormalized database
I ended up using the hibernate configuration tools to help me generate those entity classes. For tables that doesn't have a primary key, the hibernate configuration tools will generate one extra class to store a value called ID (for mapping purposes), and I might have to manually delete those classes.
http://hibernate.org/tools/
In our project we have a constraint of not having the luxury to alter the table structure already in place. The tables are highly denormalized in nature.
We have come up with good POJOs for the application. We have the Entity beans generated out of the exiting tables. Now we have to map the POJOs to the entities so that we can persist.
Ultimately, we combine a good POJO with a bad table. Any thoughts on options/alternatives/suggestions to this approach?
Hibernate/JPA(2) has a rich set of functionality to manipulate the mapping (so that your objects can differ from the tables), so that many (NOT ALL) old tables can be mapped to normal object. -- May you should have a look at this first, any use your pojo/table-"solution" only if this mapping is not powerful enough.
If you have a read only application, you can think of using views to make your table/views more like you objects. This may reduse the amount of strange mapping.
I don't know your mapping, size of the application or use case, but have you considered not to use Hibernate? I ask this, because I can imagine (how I said: I don't know you application), that in a architecture like this, no Hibernate feature is used and so Hibernate will add only a not needed complexity.
If you are using Hibernate you should be able to map your POJOs to the table structure using only XML files, without creating new Java beans. This would allow you to easily change the mapping if all of a sudden you can change the tables structures and make the economy of intermediary beans. That's the best you can do.
I've been dealing with composite id's and asked a few questions and I was recommended to replace my composite PK's with a single id column, and to control integrity with indexes... All of this related to the fact that mapping composite id's isn't that simple...
On the other side, some people encourage the usage of composite id's that are accord to the domain model...
So I decided to ask: When will you encourage using composite PK's in your DB while using Hibernate?
I personally favor composite ids because they emerge out of the entity-relationships. However, Hibernate suggests the use of simple integer ids. But I think you don't have to choose one over the other.
You can have your composite id constituent fields to become a <natural-id>
And have a private integral field in the class for hibernate to use as the id.
See http://docs.jboss.org/hibernate/stable/core/reference/en/html/mapping.html#mapping-declaration-naturalid