On Apr 7, 2004, at 4:59 AM, Todd O'Bryan wrote:
> P.S. Is there some semi-standard way to handle enum tables? I've
> decided I could create a superclass that has a populate() method and
> call that when I rebuild tables and such during development. Better
> ideas?
Well, to me the main inefficiency to be solved with "enumerated" or
"lookup" tables is not in finding a specific object, but rather the
fact that these read-only objects that are almost never modified in the
DB have to be fetched over and over again. The way I usually handle
this is by implementing a class-level cache, using internal DataContext
not used anywhere else in the app. When there is a need to use an
object from this cache, I apply DataContext.localObjects to transfer an
object to a target local DataContext.
E.g. if there is a persistent class called USState, USState.java might
look like that:
public class USState extends _USState {
private static Map states;
static {
// fetch all on first access.... if you don't like static
// code, or would like to supply your own DataContext,
// this can be done somewhere else
SelectQuery query = new SelectQuery(USState.class);
List allStates = DataContext.createContext().performQuery(query);
// now index states by "name" or something
states = new HashMap();
....
}
public static USState getState(String name, DataContext context) {
Object state = states.get(name);
List local =
context.localObjects(Collections.singletonList(state));
return (USState) local.get(0);
}
}
In 1.1 we may make this more transparent. Stay tuned.
Andrus
This archive was generated by hypermail 2.0.0 : Wed Apr 07 2004 - 12:07:46 EDT