Re: DataContextFactory needs ability to decorate existing DataContext

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Aug 29 2006 - 04:43:23 EDT

  • Next message: Bill Dudney: "Re: confluence maven plugin"

    Here is my thoughts on it...

    1. We may need to get rid of non-shared DataRowStore option - it
    messes things up a lot. With shared cache ObjectStore doesn't even
    need a reference to the DataRowStore and can obtain data row
    snapshots via an ObjectIdQuery. Anybody wants to keep it???

    2. The easiest way to implement decoration would be to switch the
    stack to use ObjectContext (which is an interface, defines fewer
    methods, and can be easily decorated). Now that I checked in
    RefreshQuery, users can do invalidation via ObjectContext (the only
    feature that was missing).

    With this in mind, we can have a factory like that:

    interface ObjectContextFactory {
        // "properties" map can pass DataDomain settings like validation
    flags, etc.
        // ObjectStore should be created by the factory, as the actual
    class is different
        // and sometimes not-public for different implementations of
    ObjectContext
        ObjectContext createObjectContext(DataChannel channel, Map
    properties);
    }

    On the long run we may merge it with JPA EntityManagerFactory that
    looks like this (and doesn't directly support nesting) ... but that's
    the long run.

    public interface EntityManagerFactory {
            EntityManager createEntityManager();
            EntityManager createEntityManager(Map map);
            void close();
            public boolean isOpen();
    }

    Andrus

    On Aug 27, 2006, at 2:01 AM, Mike Kienenberger wrote:

    > DataContextFactory needs the ability to decorate an existing
    > DataContext (like setting user properties or delegate) without needing
    > to create a DataContext from scratch.
    >
    > Right now it takes some really ugly code like this because the
    > lowest-level createDataContext() method checks for a
    > DataContextFactory. See last section for an example.
    >
    > I think it would be better to refactor this to provide a method
    > signature like below, and if dataContextFactory is null, then use the
    > default cayenne data context.
    >
    > public DataContext createDataContext(DataContextFactory
    > dataContextFactory, boolean useSharedCache)
    >
    > That would allow a DataContextFactory to simply call:
    >
    > DataDomain dataDomain = (DataDomain)dataChannel;
    > DataContext dataContext = dataDomain.createDataContext(null,
    > dataDomain.isSharedCacheEnabled());
    >
    > It'd be nice to make this more transparent, but I don't know if that's
    > reasonable.
    >
    > DataDomain dataDomain = (DataDomain)dataChannel;
    > DataContext dataContext = dataDomain.createDefaultDataContext
    > ();
    >
    > =================================================================
    > Example DataContextFactory:
    >
    > public DataContext createDataContext(DataDomain dataDomain) {
    > // for new dataRowStores use the same name for all stores
    > // it makes it easier to track the event subject
    > DataRowStore snapshotCache = (dataDomain.isSharedCacheEnabled
    > ())
    > ? dataDomain.getSharedSnapshotCache()
    > : new DataRowStore(dataDomain.getName(),
    > dataDomain.getProperties(), dataDomain.getEventManager());
    >
    > DataContext context;
    > context = new DataContext((DataChannel) this, new
    > ObjectStore(snapshotCache));
    > context.setValidatingObjectsOnCommit
    > (dataDomain.isValidatingObjectsOnCommit());
    > return context;
    > }
    >
    > public DataContext createDataContext(DataChannel dataChannel,
    > ObjectStore objectStore)
    > {
    > DataContext dataContext = createDataContext((DataDomain)
    > dataChannel);
    > dataContext.setDelegate(new AuditLoggingDataContextDelegate());
    > return dataContext;
    > }
    >



    This archive was generated by hypermail 2.0.0 : Tue Aug 29 2006 - 04:44:10 EDT