Forum Stats

  • 3,770,452 Users
  • 2,253,116 Discussions
  • 7,875,461 Comments

Discussions

Abstracting the Persistence API

530138
530138 Member Posts: 13
edited Sep 1, 2006 12:28PM in Berkeley DB Java Edition
Let me start by saying that I think the Persistence API in 3.0 is a great concept. My concern, however, is the apparent coupling of persistent classes to Berkeley DB. I've been racking my brain to figure out a way of abstracting things so as to isolate my domain code from the persistence details. At present, the only thing I have come up with is to maintain two mirrored class hierarchies: one for persistent classes and the other for transient classes, with a mapping layer between the two. While this concept has been proved in practice (see Stanford University's BaBar project), it's a management nightmare to try and keep two hierarchies of classes in sync.

Anyone have any suggestions?

Comments

  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    Thanks for taking a look at the DPL (Direct Persistence Layer).

    I think of persistent classes using DPL as "persistent POJOs" -- plain old Java objects that are annotated to make them persistent. The use of annotations avoids having to implement Berkeley DB interfaces or extend a Berkeley DB base class in your persistent class. In this sense, the persistent objects are not coupled to Berkeley DB. For example, they can be used along with other POJO facilities for translating between objects and XML, etc.

    In aother sense, DPL persistent classes are tied to Berkeley DB because they are accessed using the Berkeley DB APIs: PrimaryIndex, SecondaryIndex, etc. These classes are, of course, coupled directly to Berkeley DB. There is no way to transparently "swap out" Berkeley DB and "swap in" another database implementation. Is that your concern?

    Mark
  • 530138
    530138 Member Posts: 13
    Yes, the potential to change persistence implementations without having to rework my domain classes is an area of interest. Prior to DPL this was (and still is) very straightforward. The use of annotations, however, establishes a direct tie between model code and Berkeley DB classes. I suppose for the cases where this isn't acceptable we just won't use DPL.
  • If you don't wish to use annotations, you can avoid them by providing your own source of metadata. This is done by extending the EntityModel class yourself, rather than using the AnnotationModel class (which is the default). You then pass your EntityModel object to StoreConfig.setModel.

    Your implementation of EntityModel is then responsible for returning metadata about which classes are entities, which fields are keys, etc -- all the information that can be defined using the annotations. For example, you could define this information separately in an XML configuration file, and have your EntityModel return the information from the configuration file. Or you could use naming conventions, or any other technique to dereive the metadata.

    My personal opinion is that adding annotations to a class do not tightly couple the class to the meaning or use of those annotations. I believe that annotations were designed specifically so that this would be the case. For example, if you add an annotation that is not processed, this is not an error. And if you supply annotations from multiple processors (i.e, there are multiple sets of metadata), these annotations can coexist peacefully. However, that is just my opinion, and if you do not wish to use annotations for any reason, then please try using the technique I described to supply your own metadata.

    Mark
  • 530138
    530138 Member Posts: 13
    I would be more comfortable (long-term) to use annotations that are not vendor-specific. I am curious, however, as to why Sleepycat chose to implement their own rather than adopt the standard tags in the Java Persistence API, at least partially. Are they too specific to relational databases?
  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    Hi user527135,

    You're correct -- the EJB3-oriented Java Persistence API is SQL-oriented, and could not be fully implemented with Berkeley DB except by adding SQL or some other query language first.

    There was a public discussion of this issue during our design phase here:

    http://www.theserverside.com/news/thread.tss?thread_id=38916

    You should be aware that it is not just the annotation syntax that is different between DPL and the EJB3 Java Persistence API:

    - The APIs are different.
    - DPL, like other Berkeley DB APIs, accessed objects by value, while the EJB3 Java Persistence API treats object by reference and maintains a persistence context. This is discussed in TheServerSide thread above.

    In general, Berkeley DB's advantages are that it provides better performance and a simpler usage model than is possible with an SQL database. To implement the EJB3 Persistence API for Berkeley DB would negate both of these advantages.

    Mark
This discussion has been closed.