you had a table "miners" that looked like this
create table miners (
id BIGINT NOT NULL AUTO_INCREMENT,
first_name VARCHAR(255),
last_name VARCHAR(255),
primary key (id)
) Hibernate class (Miner.java) specifies the fields, getters/setters and xdoclet tags looks like so.
package deadwood;
/**//**
* @hibernate.class table="miners"
*/
public class Miner 
{
private Long id;
private String firstName;
private String lastName;
/**//**
* @hibernate.id generator-class="native"
*/
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
/**//**
* @hibernate.property column="first_name"
*/
public String getFirstName() { return firstName; }
public void setFirstName(String firstName) { this.firstName = firstName; }
/**//**
* @hibernate.property column="last_name"
*/
public String getLastName() { return lastName; }
public void setLastName(String lastName) { this.lastName = lastName; }
}
Associations
the Miner class we looked at was single table oriented, mapping to a single miners table. ORM solutions support ways to map associated tables to in memory objects ,
- Many to One/One to one - belongs_to/has_one
- One to Many (set) - has_many
- Many to Many (set) - has_and_belongs_to_many
- Single Table Inheritance
- Components (mapping > 1 object per table)
As a comparative example, lets look at the many to one relationship. We are going to expand our Deadwood example from part I. We add to the Miner a many to one association with a GoldClaim object. This means there is a foreign key, gold_claim_id in the miners table, which links it to a row in the gold_claims table.
(Java)
public class Miner {
// Other fields/methods omitted
private GoldClaim goldClaim;
/**//**
* @hibernate.many-to-one column="gold_claim_id"
* cascade="save"
*/
public GoldClaim getGoldClaim() { return goldClaim; }
public void setGoldClaim(GoldClaim goldClaim) {
this.goldClaim = goldClaim;
}
} Hibernate uses explicit mapping to specify the foreign key column, as well as the cascade behavior, which we will talk about next. Saving a
Miner will save its associated
GoldClaim, but updates and deletes to it won't affect the associated object.
Transitive Persistence
Its important for an ORM solution to provide a way to detect and cascade changes from in memory objects to the database, without the need to manually save() each one. Hibernate features a flexible and powerful version of this via declarative cascading persistence.
Deleting Hibernate offers a number of different cascading behaviors for all associations types, giving it a high degree of flexibility. For example, setting cascade="all" will make GoldClaim save, update and delete along with its parent Miner, like so...
Miner miner = new Miner();
miner.setGoldClaim(new GoldClaim());
session.save(miner); // Saves Miner and GoldClaim objects.
session.delete(miner); // Deletes both of them. By using the cascade="save-update", you could get this behavior on any association, regardless of which table the foreign key lives in. Hibernate doesn't base the transistive persistence behavior off the relationship type, but rather the cascade style, which is much more fine grained and powerful.
Query Languages
Hibernate has its own object oriented query language (Hibernate Query Language - HQL), which is deliberately very similar to SQL. How it differs is that it lets developers express their queries in terms of objects and fields instead of tables and columns. Hibernate translates the query into SQL optimized for your particular database. Obviously, inventing a new query language is very substantial task, but the expressiveness and power of it is one of Hibernate's selling points.
Querying for Objects with HQL
when you have to start navigating across objects with SQL, HQL can be very convenient alternative. Let's take a look at our sample queries for HQL.
// Find first Miner by name
Query q = session.createQuery("from Miner m where m.firstName = :name");
q.setParameter("name", "Elma");
Miner m = (Miner) q.setMaxResults(1).uniqueResult();
// Finds up to 10 miners older than 30, ordered by age.
Integer age = new Integer(30);
Query q = session.createQuery(
"from Miner m where m.age > :age order by age asc");
List miners = q.setParameter("age", age).setMaxResults(10).list();
// Similar to join query above, but no need to manually join
Query q = session.createQuery(
"from Miner m where m.goldClaim.squareArea = :area");
List minersWithSqA = q.setParameter("area", new Integer(1000)).list();
Having covered some of the basics of fetching objects, let's turn your attention to how we can make fetching objects fast. The next section covers the means by which we can tune the performance.
Performance Tuning
Beyond just mapping objects to tables, robust ORM solutions need to provide ways to tune the performance of the queries. One of the risks of working with ORM's is that you often pull back too much data from the database. This tends to happen because it its very easy to pull back several thousand rows, with multiple SQL queries, with a simple statement like "from Miner". Common ORM strategies for dealing with this include Lazy fetching, outer join fetching and caching.
What I mean by lazy is that when you fetch an object, the ORM tool doesn't fetch data from other tables, until you request the association. This prevents loading to much unneeded data. Hibernate allows you to choose which associations are lazy. This leads us to one of the great fallacies of ORM, that Lazy loading is always good. In reality, lazy loading is only good if you didn't need the data. Otherwise, you are doing with 2-1000+ queries what you could have done with one. This is dreaded N+1 select problem, where to get all the objects require N selects + 1 original selects. This problem gets much worse when you deal with collections..
Outer Joins and Explicit Fetching
Generally, one of the best way to improve performance is to limit the number of trips to the database. Better 1 big query than a few small ones. Hibernate has a number ways its handles the N+1 issue. Associations can be explicitly flagged for outer join fetching (via outer-join="true"), and you can add outer join fetching to HQL statements. For example...
/**//**
* @hibernate.many-to-one column="gold_claim_id"
* cascade="save-update" outer-join="true"
*/
public GoldClaim getGoldClaim() { return goldClaim; }
// This does one select and fetches both the Miner and GoldClaim
// and maps them correctly.
Miner m = (Miner) session.load(Miner.class, new Long(1)); In addition, when selecting lists or dealing with collection associations, you can use an explicit outer join fetch, like so...
// Issues a single select, instead of 1 + N (where N is the # miners)
List list = session.find("from Miner m left join fetch m.goldClaim"); The performance savings from this can very significant.
Caching
While object caching isn't always going to be helpful or a performance silver bullet, Hibernate has a huge potential advantage here. It provides several levels of caching, including a session (UnitOfWork) level as well as an optional second level cache. You always use the '1st level' cache, as it prevents circular references and multiple trips to the database for the same object. Using a second level cache can allow much of the database state to stay resident in memory. This is especially useful for frequently read and reference data.
方向:分布式系统设计