> About your previous post: what do you mean by "lookup
> tables" and
> "[...] and then /we/ look them up when we merge the
> object"?
Oh, we like everyone else, we have a bunch of little tables that are there mostly for doing relational integrity for things like type codes, status code. Simple tables consisting of little more than a code, short name and a description.
Like any other sane human, we dislike having to do something like:
MyObject o = new MyObject();
MyType t = em.find(MyType.class, MyType.TEST_TYPE);
o.setType(t);
...
So, instead, we can do:
MyObject o = new MyObject();
MyType t = new MyType(MyType.TEST_TYPE);
o.setType(t);
In this case, MyType is basically an empty shell.
If we were to merge the 'o' object, it will actually persist ok with the empty shell. But it pollutes the 2nd level cache. So if we later did:
MyType t = em.find(MyType.class, MyType.TEST_TYPE);
Rather than getting a fully populated class, we'd get the skeleton instead.
So, instead, we look for these kinds of classes and do the lookup when we hit the app tier.
Recall, almost all of our work is done on detached objects. Web tier massages them as appropriate, then we toss them over the session bean wall to have them persisted.
The only time we do something like what you were doing, is for our list results from our filters. There we simply fetch the primary keys, and store the primary keys in out ValueList pattern stuff. When the users pages through the screens, we just load each page from the primary keys for that page.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=224121