JDO
  1. JDO
  2. JDO-667

Extend PersistenceManageFactory to return all known entity classes

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JDO 3 (3.0)
    • Fix Version/s: JDO 3.1-rc1
    • Component/s: api, specification, tck
    • Labels:
      None

      Description

      JDO 3 now has the ability to declare meta-data programmatically. Part of this feature is the ability to ask the PersistenceManagerFactory via the method getMetadata(java.lang.String) for the meta-data of one single class. But there is no way to list all known classes.

      I therefore kindly ask for a new method in PersistenceManagerFactory like this:

      Collection<String> getClassesWithMetadata();

      Btw., this is Andy's suggestion posted here: http://www.datanucleus.org/servlet/forum/viewthread_thread,6379#33224

      I'd greatly appreciate, if this method became a part of JDO 3.1.

      Edit 1: I just saw the various overloaded methods getManagedObjects(...) in PersistenceManager - maybe the alternative method name "getManagedClasses()" would be more consistent?

      1. JDO-667-tck.patch
        4 kB
        Andy Jefferson
      2. JDO-667-api.patch
        1.0 kB
        Andy Jefferson

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        724d 21h 41m 1 Craig L Russell 19/Oct/12 17:19
        Resolved Resolved Closed Closed
        965d 20h 27m 1 Andy Jefferson 12/Jun/15 13:46
        Andy Jefferson made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Craig L Russell made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Craig L Russell added a comment -

        The following was added to Chapter 11:

        11.11 Managed Classes
        Users may obtain a collection of classes that are being managed by the PersistenceManagerFactory. These classes include those that have been referenced by any PersistenceManager instances obtained from this PersistenceManagerFactory, using methods such as getExtent, newQuery, newInstance, and makePersistent. Other classes that were loaded by the implementation based on policy or implementation-specific features might also be returned.
        The permission getMetadata must be granted to the caller or a SecurityException is thrown.
        Collection<Class> getManagedClasses();

        Show
        Craig L Russell added a comment - The following was added to Chapter 11: 11.11 Managed Classes Users may obtain a collection of classes that are being managed by the PersistenceManagerFactory. These classes include those that have been referenced by any PersistenceManager instances obtained from this PersistenceManagerFactory, using methods such as getExtent, newQuery, newInstance, and makePersistent. Other classes that were loaded by the implementation based on policy or implementation-specific features might also be returned. The permission getMetadata must be granted to the caller or a SecurityException is thrown. Collection<Class> getManagedClasses();
        Hide
        Andy Jefferson added a comment -

        Patches now applied to SVN trunk

        Show
        Andy Jefferson added a comment - Patches now applied to SVN trunk
        Andy Jefferson made changes -
        Assignee Craig L Russell [ clr ]
        Andy Jefferson made changes -
        Attachment JDO-667-api.patch [ 12512296 ]
        Attachment JDO-667-tck.patch [ 12512297 ]
        Hide
        Andy Jefferson added a comment -

        Patches for api/tck to add getManagedClasses to PMF and add simple test for presence of Extent/Query class being present

        Show
        Andy Jefferson added a comment - Patches for api/tck to add getManagedClasses to PMF and add simple test for presence of Extent/Query class being present
        Hide
        Craig L Russell added a comment -

        Is there a patch for this issue?

        Show
        Craig L Russell added a comment - Is there a patch for this issue?
        Hide
        Michael Bouschen added a comment -

        I agree getMetadata sounds like the right permission.

        I think we need a spec update and a tck test.

        Show
        Michael Bouschen added a comment - I agree getMetadata sounds like the right permission. I think we need a spec update and a tck test.
        Michael Bouschen made changes -
        Component/s api [ 11653 ]
        Component/s specification [ 12311332 ]
        Component/s tck [ 11652 ]
        Hide
        Craig L Russell added a comment -

        Hi Erik,

        We have a permission that sounds suitable: getMetadata

        WDYT?

        Show
        Craig L Russell added a comment - Hi Erik, We have a permission that sounds suitable: getMetadata WDYT?
        Hide
        Erik Bengtson added a comment -

        This method should check for permission, otherwise it may expose data that hackers could use to explore the user data model

        Show
        Erik Bengtson added a comment - This method should check for permission, otherwise it may expose data that hackers could use to explore the user data model
        Hide
        Andy Jefferson added a comment -

        FYI. DataNucleus v2.2.x has a method
        Collection<Class> PMF.getManagedClasses()

        Show
        Andy Jefferson added a comment - FYI. DataNucleus v2.2.x has a method Collection<Class> PMF.getManagedClasses()
        Hide
        Craig L Russell added a comment -

        Given that the JDO implementation keeps track of persistence-capable and persistence-aware classes, it makes sense for the application to get the collection of such classes.

        And given that it's awkward for the application itself to manage the name-to-class mapping, it also makes sense for the return type of the PersistenceManagerFactory getManagedClasses() method to be Collection<java.lang.Class<?>>.

        As far as the requirements for what classes are returned, I'd say it should be pretty loose. I agree with you that the result must include all classes that have been referenced by all PMs obtained from the PMF. Referenced would be those as parameters in getExtent(...), newQuery(...), makePersistent(...).

        I'd also add that the result may include other classes that the implementation has loaded based on implementation policy or non-standard features.

        Show
        Craig L Russell added a comment - Given that the JDO implementation keeps track of persistence-capable and persistence-aware classes, it makes sense for the application to get the collection of such classes. And given that it's awkward for the application itself to manage the name-to-class mapping, it also makes sense for the return type of the PersistenceManagerFactory getManagedClasses() method to be Collection<java.lang.Class<?>>. As far as the requirements for what classes are returned, I'd say it should be pretty loose. I agree with you that the result must include all classes that have been referenced by all PMs obtained from the PMF. Referenced would be those as parameters in getExtent(...), newQuery(...), makePersistent(...). I'd also add that the result may include other classes that the implementation has loaded based on implementation policy or non-standard features.
        Hide
        Marco added a comment - - edited

        Hi Craig,

        thanks a lot for your very quick response! Unfortunately, I can't promise. I'm currently very busy with a customer's project. If the project ends as planned, I'll have the first December week time for writing the technical description. But if the project becomes delayed, I can't say for sure, yet, and I'll be in holidays afterwards (till the end of January).

        Concerning the appearance of the class, I'd say it should be in the list as soon as the JDO implementation initialises its meta-data. This means normally when getExtent(...), newQuery(...), makePersistent(...) or sth. similar is called the first time.

        Additionally, if the implementation remembers all previously managed classes like DataNucleus can - http://www.datanucleus.org/products/accessplatform_2_2/jdo/autostart.html -, the classes should be enlisted directly at start-up.

        This behaviour is IMHO quite straight-forward and probably what DataNucleus already does internally.

        Show
        Marco added a comment - - edited Hi Craig, thanks a lot for your very quick response! Unfortunately, I can't promise. I'm currently very busy with a customer's project. If the project ends as planned, I'll have the first December week time for writing the technical description. But if the project becomes delayed, I can't say for sure, yet, and I'll be in holidays afterwards (till the end of January). Concerning the appearance of the class, I'd say it should be in the list as soon as the JDO implementation initialises its meta-data. This means normally when getExtent(...), newQuery(...), makePersistent(...) or sth. similar is called the first time. Additionally, if the implementation remembers all previously managed classes like DataNucleus can - http://www.datanucleus.org/products/accessplatform_2_2/jdo/autostart.html -, the classes should be enlisted directly at start-up. This behaviour is IMHO quite straight-forward and probably what DataNucleus already does internally.
        Hide
        Craig L Russell added a comment -

        Could you write up a technical description of the method suitable for inclusion in the specification, and think about writing test cases?

        When does a class appear in the list? In JDO, classes and metadata are loaded lazily, so we need to decide when a class is required to be in the list, and when a class is allowed to be in the list.

        Show
        Craig L Russell added a comment - Could you write up a technical description of the method suitable for inclusion in the specification, and think about writing test cases? When does a class appear in the list? In JDO, classes and metadata are loaded lazily, so we need to decide when a class is required to be in the list, and when a class is allowed to be in the list.
        Hide
        Marco added a comment -

        I just added JDO-668 and am thinking a bit more about the Class vs. className[String] question. Is there a certain reason, why the meta-data methods don't work with java.lang.Class? Would it be inconsistent to make the new method getClassesWithMetadata() or getManagedClasses() return a Collection<java.lang.Class>?

        Show
        Marco added a comment - I just added JDO-668 and am thinking a bit more about the Class vs. className [String] question. Is there a certain reason, why the meta-data methods don't work with java.lang.Class? Would it be inconsistent to make the new method getClassesWithMetadata() or getManagedClasses() return a Collection<java.lang.Class>?
        Marco made changes -
        Field Original Value New Value
        Description JDO 3 now has the ability to declare meta-data programmatically. Part of this feature is the ability to ask the PersistenceManagerFactory via the method getMetadata(java.lang.String) for the meta-data of one single class. But there is no way to list all known classes.

        I therefore kindly ask for a new method in PersistenceManagerFactory like this:

        Collection<String> getClassesWithMetadata();

        Btw., this is Andy's suggestion posted here: http://www.datanucleus.org/servlet/forum/viewthread_thread,6379#33224

        I'd greatly appreciate, if this method became a part of JDO 3.1.
        JDO 3 now has the ability to declare meta-data programmatically. Part of this feature is the ability to ask the PersistenceManagerFactory via the method getMetadata(java.lang.String) for the meta-data of one single class. But there is no way to list all known classes.

        I therefore kindly ask for a new method in PersistenceManagerFactory like this:

        Collection<String> getClassesWithMetadata();

        Btw., this is Andy's suggestion posted here: http://www.datanucleus.org/servlet/forum/viewthread_thread,6379#33224

        I'd greatly appreciate, if this method became a part of JDO 3.1.

        Edit 1: I just saw the various overloaded methods getManagedObjects(...) in PersistenceManager - maybe the alternative method name "getManagedClasses()" would be more consistent?
        Marco created issue -

          People

          • Assignee:
            Craig L Russell
            Reporter:
            Marco
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development