Re: Loading small tables into memory for the application lifetime

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Jun 30 2008 - 11:47:34 EDT

  • Next message: Řyvind Harboe: "Re: Loading small tables into memory for the application lifetime"

    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