db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Dependencies between ri11 runtime and r11 query
Date Fri, 29 Apr 2005 22:35:57 GMT
Hi Michael,

Thanks for this analysis.

On Apr 28, 2005, at 11:16 AM, Michael Watzek wrote:

> Hi,
>
> Micheal Bouschen raised the issue to get rid of the compile time 
> dependencies between ri11 runtime and ri11 query. The benefit would 
> be:
>
> 1) Runtime and query could be separated into 2 different projects.
> 2) ri11 runtime could be executed with another query implementation.
> 3) ri11 query could be executed with another runtime implementation.
>
> Below, I summerize what code changes have to be done to achieve issue 
> 2).
>
> There are only 2 dependencies from runtime implementation to query 
> implementation:
>
> - PersistenceManagerFactoryImpl calls Tree constructor
> - PersistenceManagerImpl calls QueryImpl constructors

What if we move the method newQueryTree from PMFImpl to the FOStorePMF 
class?

Similarly, we can move the nine newQueryXXX methods from PMImpl to 
FOStorePM.

If we break this dependency, we could keep the dependency from Query to 
Runtime. And not implement part 3 as outlined below. I think part 3 is 
a lot of work and still doesn't remove the dependencies.

(The proposal below still requires the Query to know about 
StateManagerInternal, FieldManager, and StoreManager which I guess are 
still defined in Runtime.)

So the new proposal is to break out ri11 into

core20 (model plus utility): no dependencies
enhancer20: depends on core
runtime20: depends on core
query20: depends on runtime and core
fostore20: depends on core, runtime, and query

Craig
>
> The proposal is to introduce a new runtime interface QueryFactory 
> which defines methods creating QueryTree instances and Query 
> instances, e.g.
>
> public interface QueryFactory
> {
>     QueryTree createTree();
>     Query createQuery(...);
> }
>
> This interface is implemented by query implementations. The ri11 query 
> implementation calls the Tree and QueryImpl constructors.
>
> Additionally, ri11 runtime defines a new PMFInternal property 
> containing the class name of the QueryFactory implementation. The 
> property may be specified by a Properties instance which is passed to 
> JDOHelper.getPersistenceManagerFactory, or it may be set calling a 
> setter on the PMFInternal instance. The PMFInternal instance looks up 
> the implementation class and calls newInstance() in order to create a 
> QueryFactory instance. The class object is kept in an instance 
> variable. The Tree and QueryImpl constructor calls in 
> PersistenceManagerFactoryImpl and PersistenceManagerImpl are replaced 
> by corresponding calls on the QueryFactory instance.
>
> Constraints on the QueryFactory implementation class: It must 
> implement a public no argument constructor.
>
>
> Below, I summerize what code changes have to be done to achieve issue 
> 3).
>
> The ri11 query implementation does not have references into runtime 
> implementation packages, such as "org.apache.jdo.impl.pm" or 
> "org.apache.jdo.impl.state". However, it has some references into 
> runtime specific interfaces like PersistenceManagerInternal (PMI) and 
> StateManagerInternal (SMI):
>
> - PMI.findStateManager(...)
> - PMI.loadClass(...)
> - PMI.assertIsOpen()
> - PMI.getStoreManager()
> - PMI.getCurrentWrapper()
> - SMI.provideField(...)
>
> Additionally, there is a dependency to the FieldManager interface: As 
> query implementation calls method SMI.provideField(...) having a field 
> manager parameter, it provides an implementation for that interface 
> and passes an instance of that implementation.
>
> The proposal is to define a new query interface RuntimeContext 
> defining all of the methods above, e.g.
>
> interface RuntimeContext
> {
>     StateManager findStateManager(PersistenceCapable pc);
>     Class loadClass(String name, ClassLoader given) throws 
> ClassNotFoundException;
>     void assertIsOpen();
>     StoreManager getStoreManager();
>     PersistenceManager getCurrentWrapper();
>     void provideField(int fieldNumber, FieldManager fieldManager, 
> boolean identifying);
> }
>
> This interface is implemented by runtime implementations. A query 
> instance has an instance of this interface which it gets through a 
> parameter of query factory method "createQuery", e.g.
>
> QueryFactory.createQuery(..., RuntimeContext context);
>
> All calls of the methods above are replaced by corresponding method 
> calls on RuntimeContext instance.
>
> Drawbacks of this proposal: It does not eliminate the dependency to 
> the FieldManager interface.
>
> Advantages of this proposal: It gathers all runtime calls in an single 
> instance implementing a small API, rather than having calls on 2 
> different instances each of which implements a big API (PMI defines 23 
> methods, SMI defines 33 meethods).
>
> Regards,
> Michael
> -- 
> -------------------------------------------------------------------
> Michael Watzek                  Tech@Spree Engineering GmbH
> mailto:mwa.tech@spree.de        Buelowstr. 66
> Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
> Fax.:  ++49/30/217 520 12       http://www.spree.de/
> -------------------------------------------------------------------
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Mime
View raw message