But every ORM framework will tell you that the “many” side of the relationship should be the owning side and the “one” side is the inverse. Why? Let’s look at some Java class definitions using JPA.

@Entity
public class Customer implements Serializable {
	@Id
	public String id;

	public String name;
	public String emailAddress;

	@OneToMany
	List<Order> order = new ArrayList<Order>();

	@Version
	public int version;

}

A Customer has a one-to-many relationship with Order.

@Entity
@Table(name="orders")
public class Order implements Serializable {
	@Id
	public String id;

	@ManyToOne
	Customer customer;

}

And the Order references the customer to which it belongs. Here is our bi-directional relationship. But we don’t know why the Order is the owning-side of the relationship yet. If we were to create a database schema based on these classes we would get three tables:

mysql> describe Customer;
+--------------+--------------+------+-----+---------+-------+
| Field        | Type         | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+-------+
| id           | varchar(255) | NO   | PRI | NULL    |       |
| emailAddress | varchar(255) | YES  |     | NULL    |       |
| name         | varchar(255) | YES  |     | NULL    |       |
| version      | int(11)      | YES  |     | NULL    |       |
+--------------+--------------+------+-----+---------+-------+

mysql> describe customer_orders;
+-------------+--------------+------+-----+---------+-------+
| Field       | Type         | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| CUSTOMER_ID | varchar(255) | YES  | MUL | NULL    |       |
| ORDER_ID    | varchar(255) | YES  | MUL | NULL    |       |
+-------------+--------------+------+-----+---------+-------+

mysql> describe orders;
+-------------+--------------+------+-----+---------+-------+
| Field       | Type         | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| id          | varchar(255) | NO   | PRI | NULL    |       |
| CUSTOMER_ID | varchar(255) | YES  | MUL | NULL    |       |
+-------------+--------------+------+-----+---------+-------+

The tables that map to our entities look fine. We also get a join table to map from Customer to Order. Even though the Order class can refer directly to its Customer the Customer must look at the join table to get to its Orders.

The SQL query generated by the ORM to get the Orders associated with a customer would join the customer_orders table to get a list of order ids associated with that customer, then join the orders table on those order ids. There is a more direct way we can get there, especially since the orders table already references its customer id. We need to indicate to the JPA runtime that the Customer can reference a column on the orders table. We do that with the mappedBy attribute in @OneToMany.

@Entity
public class Customer implements Serializable {
	@Id
	public String id;

	public String name;
	public String emailAddress;

	@OneToMany(mappedBy="customer")
	List<Order> order = new ArrayList<Order>();

	@Version
	public int version;

}

When we add the mappedBy attribute on the @OneToMany annotation the JPA runtime knows that there is a field in the related object named customer. The column this field maps to is the appropriate foreign key to use to find associated Orders. Creating the database schema with this change to the Customer class @OneToMany annotation we get only two tables.

mysql> describe Customer;
+--------------+--------------+------+-----+---------+-------+
| Field        | Type         | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+-------+
| id           | varchar(255) | NO   | PRI | NULL    |       |
| emailAddress | varchar(255) | YES  |     | NULL    |       |
| name         | varchar(255) | YES  |     | NULL    |       |
| version      | int(11)      | YES  |     | NULL    |       |
+--------------+--------------+------+-----+---------+-------+
4 rows in set (0.01 sec)

mysql> describe orders;
+-------------+--------------+------+-----+---------+-------+
| Field       | Type         | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| id          | varchar(255) | NO   | PRI | NULL    |       |
| CUSTOMER_ID | varchar(255) | YES  | MUL | NULL    |       |
+-------------+--------------+------+-----+---------+-------+
2 rows in set (0.01 sec)

Now the JPA runtime knows that the customer_id column on the orders table can map between an Order and a Customer. The owning-side of a bidirectional relationship is the one with the foreign key column on the table – the orders table. The orders table owns the relationship because it is responsible for the column that maps between Customer and Order. The “owning-side” is not a statement about a Customer has many Orders, the logical relationship between entities. It is a statement about which underlying table is responsible for the mapping data between two tables and the entities mapped by those tables.

I was just reminded of my initial questions about why we use these terms when I wrote a @OneToMany(mappedBy=”…”) a few days ago. As always I’m open to comments.

This is the first time we’ve done the round-table style meeting and I’m excited to see how it goes.  Guests are encouraged to come prepared with questions, answers and opinions on application scalability tools, strategies and designs.  Hot topics will include platform and software stack, cloud computing and resources, vendor tools and support and CDNs. Those are my guesses about hot topics doesn’t mean the meeting is limited to those topics.

Guests, be the regular or first-timers, will drive the direction of the discussion.  We’ll talk about solving technical problems based on past experience or serve as an advisory panel on where and when to use a particular tool.

Full meeting details are at the BostonSUG web site.  We ask that you sign up for the meeting at the meeting registration page so we have an idea of how much food to buy.  There will be snacks and bottled water at this meeting.

Hope to see everyone on the 28th at 6 p.m.!

Right away it looks like this query will get very expensive for large tag sets. For smaller sets the query performs in a reasonable amount of time but more than 12 tags makes the query take quite a while. This is exacerbated by the fact that this query will be executed multiple times if there is a sufficiently large result set (default is over 25) to give the user a paginated view. This totally flies in the face of being nice to the database. Hammering it with a complex query over and over won’t do the users any favors.

What are my options here? I can work on making this query less complex (something that I will certainly do), but there is still the problem that, no matter how nice this query becomes, the query will be executed over and over as a user pages through the results. The complexity of the query and its repeated execution makes the result set a good candidate for caching. Caching the result set in memory with a key tied to the user or their session will allow the expensive query to be executed once with the bookmarks stored in a cache. When the user pages through the results the cache will be consulted first where the result set will be stored. I’m in the process of selecting a caching package for this project so I will post my selection and integration process soon.

Until then, I’d be happy to hear any suggestions on making this query a little nicer while preserving its “andness”.