Cascading and app design considerations using business key

mlib_hibernate · **Joined:** Tue May 15, 2007 6:46 am **Posts:** 1

Hi folks-

So let me preemptively say that I am new to hibernate. Prior to this I was using ibatis. iBatis is nice but hibernate is the future. I just about finished the HiA book but i am still left wanting with regards to how I can use the full power of the ORM with an application that I'm developing. Like I said I have read HiA and searched this forum but with no success. To summarize, I am developing a results database for all our tests. One of the use cases that we are developing for is the following:

An engineer develops a automation script. As a final task for his test, he will persist the result of his script as well as any other metadata that is associated with that result(i.e. a test case entity) through the application we are developing. As part of the design consideration is whether or not to expose the concept of the test case id to the user. The reason for this is that if the engineer runs his script for the first time, calls our application to persist that data hibernate will see object graph and realize that the associated meta-data (test case among others) is new and will do a cascade save (so there is a one-to-many relationship between result and test case.... test case can have many results). If the engineer runs the script again the result entity is new but the test case remains the same.

So this is were I am left questioning how to deal with this association. If I work with an id as the surrogate key for the testcase (testcase_id) then I can return this to the automation engineer and the next time he executes his script, he rewrites a portion to include this surrogate key. This solution is not acceptable. So as mentioned in HiA the surrogate key is used for the convenience of the persistence layer and might not be appropriate to expose to the user.

Now HiA recommends using a business key and implement the equals and hashcode. I can do that as well. So in the layer that has my business logic, i could take the incoming result-testcase pair, do a find on the testcase table on the business key. If that tuple exist, associate the result with the testcase (via

Code:

update(testcase.addtoResultSet(result)).

If I dont have the testcase in the table I have to create a new record in the testcase table then save.

Code:

save(testcase.addtoResultSet(result)).

I don't think I can use saveorUpdate since in both instances the testcase_id would be null. How does hibernate know whether an object is detached or transient if we are not using a surrogate key. Also in this situation do I loose the cascading feature of hibernate since I am not using surrogate keys?

Sorry if this is such a noob question. I am having a hard time wrapping my head around this.

Thanks

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

mlib_hibernate wrote:

If that tuple exist, associate the result with the testcase (via

update(testcase.addtoResultSet(result)).

If I dont have the testcase in the table I have to create a new record in the testcase table then save.

save(testcase.addtoResultSet(result)).

You have all the steps, it looks like you're making a bad assumption though. This is the logic:

Code:

Query q  = session.getNamedQuery("testCaseByBusinessKey");
q.setString("businessKey", testCaseName);
TestCase tc = q.uniqueResult();
if (tc == null)
{
  // create new test case, add result to its collection of results
  session.save(tc); // cascade-saves result.
}
else
{
  tc.getResults().add(result);
  session.update(tc); // cascades
}