On Jun 30, 2008, at 6:33 PM, Mike Kienenberger wrote:
> But what about putting the constant tables into a parent DataContext,
> then doing all of your work in the child DataContext? Does that
> remove the need for using localObject, but still give you the
> flexibility to toss the child context objects?
That won't work directly, you still have to get a local object (it
won't be fetched from DB, and rather resolved from memory, but still).
But here is another way to work with lookup tables in 3.0 - use shared
caching... So locally you'd do this:
// you don't have to make it static; just wanted to point out
// that the query object itself is reusable (as long as there is no
parameters)
// This query can be mapped in the Modeler just as well.
static final SelectQuery countriesQuery = new
SelectQuery(Country.class);
static {
countriesQuery.setCacheStrategy(QueryCacheStrategy.SHARED_CACHE);
}
public void myNonStaticMethod() {
...
List localCountries = context.performQuery(countriesQuery);
}
There is some overhead with the shared cache access, but still with
this approach you don't have to mess with 'localObject'. I'd say this
is an ideal separation of code from configuration.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jun 30 2008 - 11:48:07 EDT