JDO
  1. JDO
  2. JDO-630

Support specification of exact class in SingleFieldIdentity

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: JDO 3 (3.0)
    • Component/s: specification, tck
    • Labels:
      None

      Description

      When calling PersistenceManager.getObjectById() with a SingleFieldIdentity, there seems to be no way of avoiding the following
      (if the implementation decides to do so):
      "It is an implementation decision whether to access the data store, if required to determine the exact class. This will be the case of inheritance, where multiple <code>PersistenceCapable</code> classes share the same ObjectId class."

      Now when I know for sure that the targetClassName of the given SingleFieldIdentity already denotes the correct class for the given id, how can I avoid that additional roundtrip to the database for finding the exact class?

      It would be useful to have a way of specifying a SingleFieldIdentity to be for the exact class specified. This could be done by addition of methods
      void setExact(boolean flag);
      boolean getExact();
      to SingleFieldIdentity

      1. jdo-630.patch
        34 kB
        Craig L Russell

        Activity

        Hide
        Craig L Russell added a comment -

        The snapshot of DataNucleus 2.0.1 resolves this issue.

        Show
        Craig L Russell added a comment - The snapshot of DataNucleus 2.0.1 resolves this issue.
        Hide
        Andy Jefferson added a comment -

        DN SVN trunk now passes JDO2 TCK. Marking unassigned in case some more is required on this (e.g in the spec to say that if the user is handed an object at an incorrect inheritance level, then at first load of fields a JDOObjectNotFoundException will be thrown).

        Show
        Andy Jefferson added a comment - DN SVN trunk now passes JDO2 TCK. Marking unassigned in case some more is required on this (e.g in the spec to say that if the user is handed an object at an incorrect inheritance level, then at first load of fields a JDOObjectNotFoundException will be thrown).
        Hide
        Craig L Russell added a comment -

        Missed the orm file in the previous commit.

        svn commit -m "Missed the orm in the commit" src/orm/applicationidentity/org/apache/jdo/tck/pc/singlefieldidentity/package-standard.orm
        Sending src/orm/applicationidentity/org/apache/jdo/tck/pc/singlefieldidentity/package-standard.orm
        Transmitting file data .
        Committed revision 903085.

        Show
        Craig L Russell added a comment - Missed the orm file in the previous commit. svn commit -m "Missed the orm in the commit" src/orm/applicationidentity/org/apache/jdo/tck/pc/singlefieldidentity/package-standard.orm Sending src/orm/applicationidentity/org/apache/jdo/tck/pc/singlefieldidentity/package-standard.orm Transmitting file data . Committed revision 903085.
        Hide
        Craig L Russell added a comment -

        I've committed changes as a result of the review comments.

        Assigning to Andy to resolve the failures.

        svn commit src/java/org/apache/jdo/tck/pc/singlefieldidentity src/java/org/apache/jdo/tck/api/persistencemanager/getobject/GetObjectByIdExactClass.java src/conf/pm.conf src/jdo/applicationidentity/org/apache/jdo/tck/pc
        Sending src/conf/pm.conf
        Adding src/java/org/apache/jdo/tck/api/persistencemanager/getobject/GetObjectByIdExactClass.java
        Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/Employee.java
        Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/FullTimeEmployee.java
        Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/PartTimeEmployee.java
        Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/Person.java
        Sending src/jdo/applicationidentity/org/apache/jdo/tck/pc/singlefieldidentity/package.jdo
        Transmitting file data .......
        Committed revision 903076.

        Show
        Craig L Russell added a comment - I've committed changes as a result of the review comments. Assigning to Andy to resolve the failures. svn commit src/java/org/apache/jdo/tck/pc/singlefieldidentity src/java/org/apache/jdo/tck/api/persistencemanager/getobject/GetObjectByIdExactClass.java src/conf/pm.conf src/jdo/applicationidentity/org/apache/jdo/tck/pc Sending src/conf/pm.conf Adding src/java/org/apache/jdo/tck/api/persistencemanager/getobject/GetObjectByIdExactClass.java Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/Employee.java Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/FullTimeEmployee.java Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/PartTimeEmployee.java Adding src/java/org/apache/jdo/tck/pc/singlefieldidentity/Person.java Sending src/jdo/applicationidentity/org/apache/jdo/tck/pc/singlefieldidentity/package.jdo Transmitting file data ....... Committed revision 903076.
        Hide
        Craig L Russell added a comment -

        Review during conference call:

        comment regarding PartTimeEmployee is wrong; should be FullTimeEmployee
        remove occurrences of system.out.println; replace with log.debug
        testConcreteSuperclassExact test case is wrong; should expect exactly Person.class not instanceof test; then should fail when any database access (access to a non-id field) discovers wrong class
        testWrongClass: message needs clarification

        Show
        Craig L Russell added a comment - Review during conference call: comment regarding PartTimeEmployee is wrong; should be FullTimeEmployee remove occurrences of system.out.println; replace with log.debug testConcreteSuperclassExact test case is wrong; should expect exactly Person.class not instanceof test; then should fail when any database access (access to a non-id field) discovers wrong class testWrongClass: message needs clarification
        Hide
        Craig L Russell added a comment -

        Not clear what you are looking for. The stack trace is above:
        [java] There was 1 error:
        [java] 1) testAbstractSuperclassExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)java.lang.NullPointerException
        [java] at org.datanucleus.state.JDOStateManagerImpl.cache(JDOStateManagerImpl.java:659)
        [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2CacheInternal(ObjectManagerImpl.java:3916)
        [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2Cache(ObjectManagerImpl.java:3893)
        [java] at org.datanucleus.ObjectManagerImpl.findObject(ObjectManagerImpl.java:2821)
        [java] at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1640)
        [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testAbstractSuperclassExact(GetObjectByIdExactClass.java:109)

        Show
        Craig L Russell added a comment - Not clear what you are looking for. The stack trace is above: [java] There was 1 error: [java] 1) testAbstractSuperclassExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)java.lang.NullPointerException [java] at org.datanucleus.state.JDOStateManagerImpl.cache(JDOStateManagerImpl.java:659) [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2CacheInternal(ObjectManagerImpl.java:3916) [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2Cache(ObjectManagerImpl.java:3893) [java] at org.datanucleus.ObjectManagerImpl.findObject(ObjectManagerImpl.java:2821) [java] at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1640) [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testAbstractSuperclassExact(GetObjectByIdExactClass.java:109)
        Hide
        Andy Jefferson added a comment -

        Re: The NPE is here
        Errm, no, you misunderstand . I want to *see* the NPE and its stack trace ... which is presumably in DN code. Without that I would have to run the test that isn't present in SVN

        Show
        Andy Jefferson added a comment - Re: The NPE is here Errm, no, you misunderstand . I want to * see * the NPE and its stack trace ... which is presumably in DN code. Without that I would have to run the test that isn't present in SVN
        Hide
        Craig L Russell added a comment -

        Just a couple of comments on the test case:

        This uses the structure of the company model with class Person with the id; abstract class Employee extends Person; class PartTimeEmployee extends Employee; and FullTimeEmployee extends Employee. The mapping uses single table for all classes with a discriminator column.

        The error is NPE when getting the object by id where the oid is Employee, validate false.

        The failures are when getting the object by id where the oid is Person, whether validate is true or false it returns a Person instead of a FullTimeEmployee.

        Show
        Craig L Russell added a comment - Just a couple of comments on the test case: This uses the structure of the company model with class Person with the id; abstract class Employee extends Person; class PartTimeEmployee extends Employee; and FullTimeEmployee extends Employee. The mapping uses single table for all classes with a discriminator column. The error is NPE when getting the object by id where the oid is Employee, validate false. The failures are when getting the object by id where the oid is Person, whether validate is true or false it returns a Person instead of a FullTimeEmployee.
        Hide
        Craig L Russell added a comment -

        The NPE is here:

        + /** */
        + public void testAbstractSuperclassExact() {
        + if (!runsWithApplicationIdentity()) return;
        + Transaction tx = null;
        + try

        { + pm = getPM(); + pm.currentTransaction().begin(); + // create the oid + Object abstractOid = new LongIdentity(Employee.class, id); + pm.getObjectById(abstractOid, false); <======================NPE==================== + appendMessage(ASSERTION_FAILED + "getObjectById exact for abstract superclass must fail."); + }

        catch (JDOException ex)

        { + System.out.println("testAbstractSuperclass caught correct JDOUserException: " + ex.getMessage()); + }

        + finally

        { + if ((tx != null) && tx.isActive()) + tx.rollback(); + }

        + failOnError();
        + }
        +

        Show
        Craig L Russell added a comment - The NPE is here: + /** */ + public void testAbstractSuperclassExact() { + if (!runsWithApplicationIdentity()) return; + Transaction tx = null; + try { + pm = getPM(); + pm.currentTransaction().begin(); + // create the oid + Object abstractOid = new LongIdentity(Employee.class, id); + pm.getObjectById(abstractOid, false); <======================NPE==================== + appendMessage(ASSERTION_FAILED + "getObjectById exact for abstract superclass must fail."); + } catch (JDOException ex) { + System.out.println("testAbstractSuperclass caught correct JDOUserException: " + ex.getMessage()); + } + finally { + if ((tx != null) && tx.isActive()) + tx.rollback(); + } + failOnError(); + } +
        Hide
        Andy Jefferson added a comment -

        No comment on any patch, but it would be nice to see what is this NPE and stack trace, since I don't have time to apply the patch and then run it, so if someone has it at hand posting here would be nice

        Show
        Andy Jefferson added a comment - No comment on any patch, but it would be nice to see what is this NPE and stack trace, since I don't have time to apply the patch and then run it, so if someone has it at hand posting here would be nice
        Hide
        Craig L Russell added a comment -

        Please review this patch.

        I've added a subset of the company model (just Person, Employee, PartTimeEmployee, and FullTimeEmployee) to define the classes as having LongIdentity.

        The test with the 2.0.0-release RI fails with:

        [echo] Starting configuration="clr.conf" with database="derby" identitytype="applicationidentity" mapping="" on the Reference Implementation.
        [java] RUN GetObjectByIdExactClass.testAbstractSuperclassExact ERROR
        [java] RUN GetObjectByIdExactClass.testAbstractSuperclassNotExact
        [java] RUN GetObjectByIdExactClass.testConcreteSuperclassExact FAILURE
        [java] RUN GetObjectByIdExactClass.testConcreteSuperclassNotExact FAILURE
        [java] RUN GetObjectByIdExactClass.testWrongClass
        [java] RUN GetObjectByIdExactClass.testRightClass
        [java] Description: All pmf tests with standard mapping, no testdata.
        [java] Time: 003
        [java] There was 1 error:
        [java] 1) testAbstractSuperclassExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)java.lang.NullPointerException
        [java] at org.datanucleus.state.JDOStateManagerImpl.cache(JDOStateManagerImpl.java:659)
        [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2CacheInternal(ObjectManagerImpl.java:3916)
        [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2Cache(ObjectManagerImpl.java:3893)
        [java] at org.datanucleus.ObjectManagerImpl.findObject(ObjectManagerImpl.java:2821)
        [java] at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1640)
        [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testAbstractSuperclassExact(GetObjectByIdExactClass.java:109)
        [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:272)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
        [java] There were 2 failures:
        [java] 1) testConcreteSuperclassExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)junit.framework.AssertionFailedError:
        [java] Assertion A12.5.6-??? (GetObjectById) failed: getObjectById returned wrong type org.apache.jdo.tck.pc.singlefieldidentity.Person
        [java] Assertion A12.5.6-??? (GetObjectById) failed: getObjectById exact for concrete superclass must fail.
        [java]
        [java] at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1172)
        [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testConcreteSuperclassExact(GetObjectByIdExactClass.java:169)
        [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:272)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
        [java] 2) testConcreteSuperclassNotExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)junit.framework.AssertionFailedError:
        [java] Assertion A12.5.6-??? (GetObjectById) failed: getObjectById returned wrong type org.apache.jdo.tck.pc.singlefieldidentity.Person
        [java]
        [java] at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1172)
        [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testConcreteSuperclassNotExact(GetObjectByIdExactClass.java:194)
        [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:272)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
        [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
        [java] FAILURES!!!
        [java] Error summary:
        [java] 001 error: java.lang.NullPointerException
        [java] derby-app-clr-junit.txt:
        [java] ** Tests run: 006, Time: 003 seconds. Failures: 2, Errors: 1
        [java] Excluded tests: [org.apache.jdo.tck.enhancement.FieldAccessModified, org.apache.jdo.tck.enhancement.ImplementsPersistenceCapable]
        [java] [ERROR] Java Result: 1
        [echo] Finished configuration="clr.conf" with database="derby" identitytype="applicationidentity" mapping="" on the Reference Implementation.

        Show
        Craig L Russell added a comment - Please review this patch. I've added a subset of the company model (just Person, Employee, PartTimeEmployee, and FullTimeEmployee) to define the classes as having LongIdentity. The test with the 2.0.0-release RI fails with: [echo] Starting configuration="clr.conf" with database="derby" identitytype="applicationidentity" mapping="" on the Reference Implementation. [java] RUN GetObjectByIdExactClass.testAbstractSuperclassExact ERROR [java] RUN GetObjectByIdExactClass.testAbstractSuperclassNotExact [java] RUN GetObjectByIdExactClass.testConcreteSuperclassExact FAILURE [java] RUN GetObjectByIdExactClass.testConcreteSuperclassNotExact FAILURE [java] RUN GetObjectByIdExactClass.testWrongClass [java] RUN GetObjectByIdExactClass.testRightClass [java] Description: All pmf tests with standard mapping, no testdata. [java] Time: 003 [java] There was 1 error: [java] 1) testAbstractSuperclassExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)java.lang.NullPointerException [java] at org.datanucleus.state.JDOStateManagerImpl.cache(JDOStateManagerImpl.java:659) [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2CacheInternal(ObjectManagerImpl.java:3916) [java] at org.datanucleus.ObjectManagerImpl.putObjectIntoLevel2Cache(ObjectManagerImpl.java:3893) [java] at org.datanucleus.ObjectManagerImpl.findObject(ObjectManagerImpl.java:2821) [java] at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1640) [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testAbstractSuperclassExact(GetObjectByIdExactClass.java:109) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:272) [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) [java] There were 2 failures: [java] 1) testConcreteSuperclassExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)junit.framework.AssertionFailedError: [java] Assertion A12.5.6-??? (GetObjectById) failed: getObjectById returned wrong type org.apache.jdo.tck.pc.singlefieldidentity.Person [java] Assertion A12.5.6-??? (GetObjectById) failed: getObjectById exact for concrete superclass must fail. [java] [java] at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1172) [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testConcreteSuperclassExact(GetObjectByIdExactClass.java:169) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:272) [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) [java] 2) testConcreteSuperclassNotExact(org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass)junit.framework.AssertionFailedError: [java] Assertion A12.5.6-??? (GetObjectById) failed: getObjectById returned wrong type org.apache.jdo.tck.pc.singlefieldidentity.Person [java] [java] at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1172) [java] at org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectByIdExactClass.testConcreteSuperclassNotExact(GetObjectByIdExactClass.java:194) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:272) [java] at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) [java] at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) [java] at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) [java] FAILURES!!! [java] Error summary: [java] 001 error: java.lang.NullPointerException [java] derby-app-clr-junit.txt: [java] ** Tests run: 006, Time: 003 seconds. Failures: 2, Errors: 1 [java] Excluded tests: [org.apache.jdo.tck.enhancement.FieldAccessModified, org.apache.jdo.tck.enhancement.ImplementsPersistenceCapable] [java] [ERROR] Java Result: 1 [echo] Finished configuration="clr.conf" with database="derby" identitytype="applicationidentity" mapping="" on the Reference Implementation.
        Hide
        Craig L Russell added a comment -

        To test this feature:
        Add an instance of FullTimeEmployee with identity 1.

        Object oid = new LongIdentity(PartTimeEmployee.class, 1);

        try

        { PartTimeEmployee pto = pm.getObjectById(oid, false); pto.getName(); }

        catch (JDOException ex)

        { // must fail }

        try { Object oid = new IntIdentity(PartTimeEmployee.class, 1); } catch (JDOException ex) { // must fail }

        Other cases with Person must also fail.

        Show
        Craig L Russell added a comment - To test this feature: Add an instance of FullTimeEmployee with identity 1. Object oid = new LongIdentity(PartTimeEmployee.class, 1); try { PartTimeEmployee pto = pm.getObjectById(oid, false); pto.getName(); } catch (JDOException ex) { // must fail } try { Object oid = new IntIdentity(PartTimeEmployee.class, 1); } catch (JDOException ex) { // must fail } Other cases with Person must also fail.
        Hide
        Andy Jefferson added a comment -

        This behaviour is implemented in the RI.

        Show
        Andy Jefferson added a comment - This behaviour is implemented in the RI.
        Hide
        Craig L Russell added a comment -

        > All objects returned by the implementation will have exact ids. All ids returned by PM.getObjectId() will also be exact.

        This seems to be the right direction. But there are a few APIs that we should revisit. Here's a proposal to change the spec but leave the API exactly as it is:

        Object getObjectById (Object oid, boolean validate);
        Add to the description of validate false:
        The user asserts that the oid contains the exact id, so if the object is not in the cache, the implementation constructs a hollow instance of the class in the oid. If the class is abstract, throw StupidUserException (we cannot construct a hollow instance of an abstract class). If the class is actually not correct, an exception with a possibly confusing error message might be thrown later. Caveat user. Test case needed.

        <T> T getObjectById (Class<T> cls, Object key);
        This is already described as having identical behavior to pm.getObjectById (pm.newObjectIdInstance (cls, key), true), so no change.

        Object getObjectById (Object oid);
        This is already described as having identical behavior to pm.getObjectById(oid, true), so no change.

        Object[] getObjectsById (boolean validate, Object... oids);
        This is defined as iterating the oids and calling getObjectById(oid, validate) so no change.

        Collection getObjectsById (Collection oids);
        This is already described as having identical behavior to pm.getObjecstById(true, oids), so no change.

        Show
        Craig L Russell added a comment - > All objects returned by the implementation will have exact ids. All ids returned by PM.getObjectId() will also be exact. This seems to be the right direction. But there are a few APIs that we should revisit. Here's a proposal to change the spec but leave the API exactly as it is: Object getObjectById (Object oid, boolean validate); Add to the description of validate false: The user asserts that the oid contains the exact id, so if the object is not in the cache, the implementation constructs a hollow instance of the class in the oid. If the class is abstract, throw StupidUserException (we cannot construct a hollow instance of an abstract class). If the class is actually not correct, an exception with a possibly confusing error message might be thrown later. Caveat user. Test case needed. <T> T getObjectById (Class<T> cls, Object key); This is already described as having identical behavior to pm.getObjectById (pm.newObjectIdInstance (cls, key), true), so no change. Object getObjectById (Object oid); This is already described as having identical behavior to pm.getObjectById(oid, true), so no change. Object[] getObjectsById (boolean validate, Object... oids); This is defined as iterating the oids and calling getObjectById(oid, validate) so no change. Collection getObjectsById (Collection oids); This is already described as having identical behavior to pm.getObjecstById(true, oids), so no change.
        Hide
        Andy Jefferson added a comment -

        Since in the weekly meeting minutes people were wanting an identity to be non-mutable from construction and after studying the usage of such identities I've come to the conclusion that it would probably be better to just add a new method on the PM (as per the original mailing list request - 22/07/2008). The only place a SingleFieldIdentity "id" can be considered "not exact" is where the user has input it into PM.getObject[s]ById(...) AFAICS. All objects returned by the implementation will have exact ids. All ids returned by PM.getObjectId() will also be exact.

        This would imply adding the following :-
        Object getObjectById(String id, boolean validate, boolean checkInheritance);
        Object[] getObjectsById(boolean validate, boolean checkInheritance, Object... ids);

        The other benefit of this would be in terms of memory, one boolean less overhead per object.

        Comments ?

        Show
        Andy Jefferson added a comment - Since in the weekly meeting minutes people were wanting an identity to be non-mutable from construction and after studying the usage of such identities I've come to the conclusion that it would probably be better to just add a new method on the PM (as per the original mailing list request - 22/07/2008). The only place a SingleFieldIdentity "id" can be considered "not exact" is where the user has input it into PM.getObject [s] ById(...) AFAICS. All objects returned by the implementation will have exact ids. All ids returned by PM.getObjectId() will also be exact. This would imply adding the following :- Object getObjectById(String id, boolean validate, boolean checkInheritance); Object[] getObjectsById(boolean validate, boolean checkInheritance, Object... ids); The other benefit of this would be in terms of memory, one boolean less overhead per object. Comments ?
        Hide
        Andy Jefferson added a comment -

        Patch for SingleFieldIdentity as per the description

        Show
        Andy Jefferson added a comment - Patch for SingleFieldIdentity as per the description

          People

          • Assignee:
            Unassigned
            Reporter:
            Andy Jefferson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development