Hi, Architecture of OpenJPA supports extension at multiple levels. Going by the list of "extension points" in your mail, I am guessing your use case will require extension both at "object management kernel" as well as in "store manager". Let me elaborate what I mean.
1. OpenJPA architecture is *strictly* layered into a object management kernel (Broker) (that knows nothing about the exact nature of the persistence data store) and a layer (StoreManager) that manages data store operations. The object management kernel also does not commit to any specific industry-standard object persistence API such as JPA or JDO. 2. This core architectural design supports JPA specification artifacts such as EntityManager as a north-bound facade to Broker and relational database as persistent datastore via JDBCStoreManager. 3. Given the above, the begin with an extension, the preliminary questions are a) does this extension change object management behavior (e.g. state interception, life-cycle management, user data representation)? b) does this extension change the data store interaction (e.g. XML database, object database)? For concrete example of (b), a separate OpenJPA called Slice is available with the distribution that adapts OpenJPA for horizontally-partitioned distributed databases, or xmlstore for a file-based storage. OpenJPA has also been extended for object databases or LDAP, but these implementations are not part of public bundles. Such extensions often extends StoreManager only. For Slice, however, EntityManager is also extended because persist() operation in a distributed database environment requires user-defined data distribution policy be called back. For concrete example of (a), look for Fluid [1] -- a project under the aegis of Apache Lab -- that extends OpenJPA to support weakly-typed data (Service Data Objects or SDO) defined on XML schema. 4. Your extension ideas also suggests that the use case requires more mapping metadata beyond JPA annotations. You are right in your hypothesis that these special annotations be parsed and registered to specialized data model classes (ClassMetaData/ClassMapping etc.). At this point, there is no provision to stick an "opaque user object" to ClassMetaData for such purpose and inheritance seems to be the option. The instance management (StateManager) layer does allow such "opaque user object" for extensions to use and interpret. Regards -- [1] Fluid: http://people.apache.org/~ppoddar/fluid/site/welcome.html ----- Pinaki -- View this message in context: http://n2.nabble.com/Architectural-overview-%28how-to-get-started-targeting-a-new-persistence-back-end%29---tp3334523p3335556.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
