Isis
  1. Isis
  2. ISIS-14

Add JDO 3.1 object store in order to support any datastore

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: objectstore-jdo-1.0.0
    • Component/s: Core
    • Labels:
      None

      Description

      Given that JDO's charter is to be datastore-agnostic, a JDO object store should be high on the list. It supports both relational and non-relational databases, including object databases, NoSQL data stores and *literally* anything else.

      By leveraging the plugins of DataNucleus, the Apache-licensed open source JDO reference implementation, the following object stores below can be supported out of the box.

      RDBMS (all major vendors)
      DB4O
      LDAP
      Excel
      XML
      Neodatis
      JSON
      ODF
      HBase

      See http://www.datanucleus.org/plugins/ for more info.

      Google's BigTable could also be supported thanks to their Google AppEngine for Java persistence solution, which is a DataNucleus plugin, enabling Isis- & JDO-based apps to run on GAEJ.

      Note that DN also supports Joda & javax.time datetime types as well.

        Activity

        Hide
        Dan Haywood added a comment -

        prior to generating 1.0.0 release notes

        Show
        Dan Haywood added a comment - prior to generating 1.0.0 release notes
        Hide
        Dan Haywood added a comment -

        Gonna mark this as fixed; reckon broken the back of it, at any rate. Could use some documentation, I suppose. But I'd rather have it out there than not ... those keen to work with it will come back to the mailing list anyway.

        Show
        Dan Haywood added a comment - Gonna mark this as fixed; reckon broken the back of it, at any rate. Could use some documentation, I suppose. But I'd rather have it out there than not ... those keen to work with it will come back to the mailing list anyway.
        Hide
        Dan Haywood added a comment -

        Hi Andy,
        yeah, I'm hitting various humps and bumps, but no show stoppers thus far. Thanks for the offer of support, will take you up on that but only if/when I really get stuck.
        Cheers
        Dan

        Show
        Dan Haywood added a comment - Hi Andy, yeah, I'm hitting various humps and bumps, but no show stoppers thus far. Thanks for the offer of support, will take you up on that but only if/when I really get stuck. Cheers Dan
        Hide
        Andy Jefferson added a comment -

        Hi Dan, just coincidence, going through all issues in Apache JIRA that mention "DataNucleus"; hadn't noticed you'd started on it Only thing to add is that while DN 3.1 is imminent (which implements JDO3.1 as well as all earlier versions), the JDO 3.1 API (provided by Apache JDO) will likely take longer and you can safely build against JDO 3.0 API since very little is changed API wise between v3.0 and v3.1 of the API. If you have any questions around getting this implemented, mail me at

        {firstname}

        AT datanucleus DOT org. Thx

        Show
        Andy Jefferson added a comment - Hi Dan, just coincidence, going through all issues in Apache JIRA that mention "DataNucleus"; hadn't noticed you'd started on it Only thing to add is that while DN 3.1 is imminent (which implements JDO3.1 as well as all earlier versions), the JDO 3.1 API (provided by Apache JDO) will likely take longer and you can safely build against JDO 3.0 API since very little is changed API wise between v3.0 and v3.1 of the API. If you have any questions around getting this implemented, mail me at {firstname} AT datanucleus DOT org. Thx
        Hide
        Dan Haywood added a comment -

        Hi Andy,
        Thanks for dropping by. Don't know if it's just a coincidence or not, you making this remark, because this issue has been lying fallow for a long while. However, I am as it happens actively working on this issue now. And yes, we had noticed 3.1 is imminent, and so we'll implement against it.
        I've changed the title of this issue to reflect.
        Cheers
        Dan

        Show
        Dan Haywood added a comment - Hi Andy, Thanks for dropping by. Don't know if it's just a coincidence or not, you making this remark, because this issue has been lying fallow for a long while. However, I am as it happens actively working on this issue now. And yes, we had noticed 3.1 is imminent, and so we'll implement against it. I've changed the title of this issue to reflect. Cheers Dan
        Hide
        Andy Jefferson added a comment -

        If this issue is seriously contemplated, use of DataNucleus v3.1 would be advisable (final release very soon) since it provides GAE support as well as more standard java types out of the box.

        Show
        Andy Jefferson added a comment - If this issue is seriously contemplated, use of DataNucleus v3.1 would be advisable (final release very soon) since it provides GAE support as well as more standard java types out of the box.
        Hide
        Mohammad Nour added a comment -

        @Matthew
        Aha, you got me , what is also good is that what you explained is not really contradicting to what I proposed, as far as I see it the implementation based on JDO/DataNucleus can then be extended to support the way I explained. Actually your idea is even better, cause this implementation way will provide us with an incremental way of development according to demand and resources we have. Good catch Matthew .

        Show
        Mohammad Nour added a comment - @Matthew Aha, you got me , what is also good is that what you explained is not really contradicting to what I proposed, as far as I see it the implementation based on JDO/DataNucleus can then be extended to support the way I explained. Actually your idea is even better, cause this implementation way will provide us with an incremental way of development according to demand and resources we have. Good catch Matthew .
        Hide
        Matthew T. Adams added a comment -

        @Mohammed,

        While I agree that the framework should allow you to select which provider you'd like to use, there remains the question of practicality in the face of limited development resources. Given that DataNucleus supports so many data stores out of the box, it seems like the Isis team should appropriately make it the first choice to support. Then, as demand increases for specific, those could be offered. In the short term, offering JDO/DataNucleus over its currently supported data stores is a huge benefit which can be expanded upon later, as demand increases.

        Thoughts?

        Show
        Matthew T. Adams added a comment - @Mohammed, While I agree that the framework should allow you to select which provider you'd like to use, there remains the question of practicality in the face of limited development resources. Given that DataNucleus supports so many data stores out of the box, it seems like the Isis team should appropriately make it the first choice to support. Then, as demand increases for specific, those could be offered. In the short term, offering JDO/DataNucleus over its currently supported data stores is a huge benefit which can be expanded upon later, as demand increases. Thoughts?
        Hide
        Mohammad Nour added a comment -

        Allow me to disagree with you:

        • IMHO it is better to treat different technologies and different providers separately.
        • For each technology, yes there is a unified interface but still we can tweak/adjust, or we can provide it to users through some more specific configurations, the generated stuff according to both criterion:
          1- Technology/API(s):
          1.1- JDO.
          1.2- JPA.
          2- Provider:
          2.1- JDO/DataNucleus.
          2.2- JPA/DataNucleus.
          2.3- JPA/Hibernate.
          2.4- JPA/OpenJPA.
        Show
        Mohammad Nour added a comment - Allow me to disagree with you: IMHO it is better to treat different technologies and different providers separately. For each technology, yes there is a unified interface but still we can tweak/adjust, or we can provide it to users through some more specific configurations, the generated stuff according to both criterion: 1- Technology/API(s): 1.1- JDO. 1.2- JPA. 2- Provider: 2.1- JDO/DataNucleus. 2.2- JPA/DataNucleus. 2.3- JPA/Hibernate. 2.4- JPA/OpenJPA.
        Hide
        Matthew T. Adams added a comment -

        @Dan, I agree.

        Show
        Matthew T. Adams added a comment - @Dan, I agree.
        Hide
        Dan Haywood added a comment -

        IMHO, this is a very good direction to take, and might well obsolete ISIS-48 (porting the existing JPA object store to OpenJPA).

        Show
        Dan Haywood added a comment - IMHO, this is a very good direction to take, and might well obsolete ISIS-48 (porting the existing JPA object store to OpenJPA).
        Hide
        Matthew T. Adams added a comment -

        I should probably also mention that DataNucleus supports JPA as well. Perhaps this could be considered the DataNucleus object store, supporting the JPA & JDO APIs and any kind of data source. With the development of this one plugin, all major APIs and data stores could be supported.

        Show
        Matthew T. Adams added a comment - I should probably also mention that DataNucleus supports JPA as well. Perhaps this could be considered the DataNucleus object store, supporting the JPA & JDO APIs and any kind of data source. With the development of this one plugin, all major APIs and data stores could be supported.

          People

          • Assignee:
            Dan Haywood
            Reporter:
            Matthew T. Adams
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development