db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: Dependencies between ri11 runtime and r11 query
Date Wed, 04 May 2005 16:44:51 GMT
Hi Craig,

I filed a JIRA issue (http://issues.apache.org/jira/browse/JDO-36) on 
the query factory prososal below. That proposal solves issue 2) below.

Attached you find an implementation for that issue which passes the ri11 
testsuite. I attached four files containing the implementation:

- rio.patch: This file contains the output of "svn diff" executed in 
directory "trunk/ri11". You can apply the patch using "patch -i 
rio.patch -p 0" in the same directory.

- 3 .java files: These files declare new classes 
org.apache.jdo.jdoql.JDOQLQueryFactory, 
org.apache.jdo.impl.jdoql.JDOQLQueryFactoryImpl, and 
org.apache.jdo.impl.fostore.FOStorePM. You *must* copy these into your 
ri11 workspace. Otherwise, the project won't compile!

The reason for the 3 .java files: I'm not familiar with "svn diff" and 
was not able to figure out how I can include new files into the patch. 
If anybody has a solution for this, please let me know.

Regards,
Michael


> Hi Michael,
> 
> On May 2, 2005, at 7:31 AM, Michael Watzek wrote:
> 
>> Hi Craig,
>>
>> please find my comments inline:
>>
>>> 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.
>>
>> The ri11 implementation does not declare a FOStore specific PM 
>> implementation. Following up your proposal, we would add a new class 
>> FOStorePM extending PMImpl. We would move all newQueryXXX methods to 
>> that class and make PMImpl abstract (removing all all newQueryXXX 
>> methods).
> 
> 
> Right. When I wrote this, I had forgotten that there was no FOStorePM! 
> But you have accurately reflected  the idea.
> 
>>
>> We could still keep the QueryFactory approach and move the interface 
>> from Runtime to Query. As an advantage, FOStore would not call 
>> constructors of the query implementation. Instead, it would create a 
>> query factory (using "Class.newInstance") and call the newQueryXXX 
>> methods. Thus, FOStore would not have compile time dependencies to the 
>> query implementation but only to the factory interface. Does this make 
>> sense?
> 
> 
> Yes. Go for it.
> 
>>
>>> 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.)
>>
>> Actually, it is not so much work. I already know all locations in the 
>> query implementation which have to be changed. The change is mostly to 
>> replace the PM instance by a RuntimeContext instance.
>>
>> However, we'd still have dependencies to FieldManager and 
>> StoreManager. We would not have dependencies to StateManager. The 
>> query implementation needs a StateManager instance to invoke 
>> "provideField". The two calls "PM.findStateManager" and 
>> "SM.provideField" can both be implemented in 
>> "RuntimeContext.provideField". For this reason, RuntimeContext would 
>> not declare method "findStateManager" (in contrast to my original 
>> proposal) and thus, would not depend on StateManager.
>>
>> Changes 2) and 3) will aproximately take a day. Please let me know 
>> which direction to go.
> 
> 
> I expect the changes for 3) will be more difficult and take more time 
> for review to make sure we get it right. So I'd like to defer this 
> exercise for now.
> 
>>> So the new proposal is to break out ri11 into
>>> core20 (model plus utility): no dependencies
>>
>> Ok.
>>
>>> enhancer20: depends on core
>>
>> Ok.
>>
>>> runtime20: depends on core
>>
>> Ok.
>>
>>> query20: depends on runtime and core
>>
>> Ok.
>>
>>> fostore20: depends on core, runtime, and query
>>
>> Ok.
> 
> 
> So the end result will be the five projects buildable and testable 
> against the api11 project library. We will then have a task to migrate 
> these projects to depend on api20 instead.
> 
> Thanks,
> 
> Craig
> 
>>
>> Thanks,
>> Michael
>>
>>> 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!
>>
>>
>>
>> -- 
>> -------------------------------------------------------------------
>> 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!


-- 
-------------------------------------------------------------------
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/
-------------------------------------------------------------------

Mime
View raw message