Hi Sriram, It largely depends on how you communicate with docbase. JPA (typically) interacts with JDBC, if there's a JDBC interface to the docbase you're using then it will be fairly straightforward to use a JPA provider to do the interactions.
If there isn't a JDBC driver for docbase then it's more difficult. OpenJPA supports different back ends, but you'd have to write a fair bit of code to talk to docbase's interface. hope this helps, -mike On Thu, May 14, 2009 at 5:26 PM, shriram <[email protected]> wrote: > Kevin, > > Actually this is how it works > > client ======>docbase(Content Server) ===> database. > (DFC-libraries) > > DFC==>Documentum Foundation Classes. > > If we are using a docbase from Documentum , is it possible for the client > to connect with docbase using JPA. > > like > > client ===>JPA===>docbase==>database > > docbase just stores meta data, whereas the actual data is still stored in > database. > > Thanks > sriram > > > > > > > ________________________________ > From: Kevin Sutter <[email protected]> > To: [email protected] > Sent: Thursday, May 14, 2009 4:53:38 PM > Subject: Re: OpenJPA for Content Servers > > Sure. Most Content Servers still require some type of database to > persistently store the "content", right? So, the implementation of a > Content Server could easily use Entities to define their data model and use > generic JPA constructs to persist the data. Independent from any > particular > database implementation (ie. not dependent on specific JDBC or SQL > dialects). Sounds like a good fit, from my personal perspective. :-) > > Kevin > > On Thu, May 14, 2009 at 12:14 PM, shriram <[email protected]> wrote: > > > Hi, > > > > I work for a Documentum Based product development company. Is there any > way > > OpenJPA applied for Content Servers. > > > > Thanks > > sriram > > > > > > > > > > > > >
