SingleFieldIdentity

[Craig Russell <Cr...@Sun.COM>]

Hi Michael,,

On Jun 29, 2005, at 3:14 AM, Michael Watzek wrote:

> Hi Craig,
>
> I like to agree on the general implementation strategy for the
> single field test cases (your issue 3). This is the proposal:
>
> We introduce new PC classes as you pointed out below for each  
> single field identity type. Furthermore, we introduce an abstract  
> super class for all tests implementing single field assertions.  
> That class extends JDO_Test and overrides method "localSetUp",  
> creating some pc instances and adding tear down classes.
>
> The tests for assertion A7.12-38 are negative tests forcing the
> implementation to throw an exception. The exception handler checks for
> JDOFatalInternalException. If it is a different exception then the  
> tests fail, else they succeed.
>
> Question: How can I force a persistent pc instance to have non- 
> initialized primary key fields?

The spec is misleading here. It currently reads as if an instance  
must be persistent before calling this method, but in fact, a  
transient instance that is becoming persistent can also supply the  
oid. So the test here should be for classes whose pk field is an  
object type. Create an instance of the class where the pk field is  
null, and the method should throw an exception.

Here's the rewritten spec:

<spec>
For classes using single field identity, this method must be called  
on an instance of a persistence-capable class with its primary key  
field initialized (not null), or a JDOFatalInternalException is thrown.
</spec>

>
> The tests for assertion A7.12-39 are positive tests, checking if  
> the key of the returned single field identity instance equals the  
> value of the primary key field.
>
> The tests for assertion A7.12-25 implement a new implementation  
> class for "PersistenceCapable.ObjectIdFieldConsumer".

You can use an inner class of the test class if that is convenient. I  
don't know that this will be used outside the test.

> They create an oid, they create a new pc instance, having different  
> primary key values compared to the oid. Afterwards, they call  
> "JDOImplHelper.copyKeyFieldsFromObjectId". Finally, they check the  
> copied values.
>
> Question: Does it make sence to implement assertion A7.12-7 [public  
> void jdoCopyKeyFieldsToObjectId(ObjectIdFieldSupplier
> fs, Object oid);] right away?

This should throw an exception for single field identity. The  
enhancement code is on Martin's list of action items. It's already  
been implemented for the CMP team and "just" needs to be ported back  
to JDO. Then it will work. But there is no harm in implementing the  
test. It's a five liner negative test.

Craig

>
> Regards,
> Michael
>
>
>> 3. Write test cases for assertions here for single field identity.  
>> Add a new property so JDO_Test can tell whether the test is being  
>> run for application identity and return without running the test  
>> if in datastore identity, similar to unsupported option. Like  
>> isRunningDatastoreIdentity and isRunningApplicationIdentity.
>> A7.12-38 [For classes using single field identity, this method  
>> must be called on a persistent instance with its primary key field  
>> initialized (not null), or a JDOFatalInternalException is thrown.]
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityNotIntializedInteger
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityNotIntializedShort
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityNotIntializedLong
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityNotIntializedCharacter
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityNotIntializedByte
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityNotIntializedString
>> A7.12-39 [The instance returned is initialized with the value of  
>> the primary key field of the instance on which the method is called.]
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedint
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedInteger
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedshort
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedShort
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedlong
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedLong
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedchar
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedCharacter
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedbyte
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedByte
>> api.persistencecapable.NewObjectIdInstance  
>> testSingleFieldIdentityInitializedString
>> A7.12-25 [public void jdoCopyKeyFieldsFromObjectId 
>> (ObjectIdFieldConsumer fc, Object oid);
>> This method copies fields to the field manager instance from the  
>> second parameter instance.
>> api.persistencecapable.CopyKeyFieldsFromObjectId  
>> testSingleFieldIdentity times 11!
>> You will need new classes and .jdo files for single field  
>> identity. Copy pc.mylib.PCPoint from application identity but  
>> redefine it to use SFI and call them  
>> pc.singlefieldidentity.PCPointSingleFieldint
>> pc.singlefieldidentity.PCPointSingleFieldInteger
>> pc.singlefieldidentity.PCPointSingleFieldshort
>> pc.singlefieldidentity.PCPointSingleFieldShort
>> pc.singlefieldidentity.PCPointSingleFieldlong
>> pc.singlefieldidentity.PCPointSingleFieldLong
>> pc.singlefieldidentity.PCPointSingleFieldchar
>> pc.singlefieldidentity.PCPointSingleFieldCharacter
>> pc.singlefieldidentity.PCPointSingleFieldbyte
>> pc.singlefieldidentity.PCPointSingleFieldByte
>> pc.singlefieldidentity.PCPointSingleFieldString
>> 4. Update existing tests or write new tests for JDO 2 JDOHelper 8.6:
>> A8.6-13 [public static
>>     PersistenceManagerFactory getPersistenceManagerFactory
>>         (File file);]
>> A8.6-14 [public static
>>     PersistenceManagerFactory getPersistenceManagerFactory
>>         (File file, ClassLoader loader);]
>> A8.6-15 [public static
>>     PersistenceManagerFactory getPersistenceManagerFactory
>>         (String resourceName);]
>> A8.6-16 [public static
>>     PersistenceManagerFactory getPersistenceManagerFactory
>>         (String resourceName, ClassLoader loader);]
>> A8.6-17 [public static
>>     PersistenceManagerFactory getPersistenceManagerFactory
>>         (InputStream stream);]
>> A8.6-18 [public static
>>     PersistenceManagerFactory getPersistenceManagerFactory
>>         (InputStream stream, ClassLoader loader);] These methods  
>> use the parameter(s) passed as arguments to construct a Properties  
>> instance, and then delegate to the static method  
>> getPersistenceManagerFactory in the class named in the property  
>> javax.jdo.PersistenceManagerFactoryClass. If there are any  
>> exceptions while trying to construct the Properties instance or to  
>> call the static method, then either A8.6-4 [JDOFatalUserException]  
>> or A8.6-5 [JDOFatalInternalException is thrown], depending on  
>> whether the exception is due to the user or the implementation.  
>> The nested exception indicates the cause of the exception.
>> api.persistencemanagerfactory.GetPMFByFile
>> api.persistencemanagerfactory.GetPMFByFileAndClassLoader
>> api.persistencemanagerfactory.GetPMFByResource
>> api.persistencemanagerfactory.GetPMFByResourceAndClassLoader
>> api.persistencemanagerfactory.GetPMFByStream
>> api.persistencemanagerfactory.GetPMFByStreamAndClassLoader
>> These test classes might use the properties that are already  
>> configured to construct the File, Resource, and Stream objects for  
>> the test (to make sure that the properties are valid for the PMF  
>> under test).
>> If you run out of work to do, please ask Michelle for her advice.
>> 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!