openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Customizing OpenJPA
Date Fri, 29 Aug 2008 13:00:21 GMT
Yuri,
I think you will find the OpenJPA is quite extensible.  We (IBM WebSphere)
have provided several value-add extensions via extending current class
implementations, or re-implementing certain interfaces.  For example, we had
originally implemented sql statement batching as an extension.  (In the next
release, we contributed this feature back to OpenJPA.)  We have done other
similar extensions in support of DB2-specific features.  So, it is doable...

But, I think you will find that it requires some effort.  In a few cases, we
had to re-work some of the current implementation within OpenJPA to allow
for the extensions.  That's acceptable as long as we don't disrupt the
existing processing.  So, depending on your extensions, you may need to work
with the OpenJPA community to get some additional changes in to make it more
extensible.  Who knows?  You may get lucky and our work may have already
paved the way for the extensions you are considering...  :-)

And, as always, during these type of exercises, contributing code and/or
documentation to make the whole OpenJPA product better will benefit all
users.  Thanks.

Good luck!
Kevin

On Fri, Aug 29, 2008 at 5:59 AM, Ignacio Andreu <plunchete@gmail.com> wrote:

> Hi Yuri,
>
> Last year I added support for "Streams" in OpenJPA, if you want to support
> new data types and you don't integrate your code inside OpenJPA there is an
> option. I extended the class
> org.apache.openjpa.jdbc.meta.strats.AbstractFieldStrategy and setting the
> option
>
> "FieldStrategies=java.io.InputStream=org.apache.openjpa.jdbc.meta.strats.LobFieldStrategy"
> take a look at the class
> org.apache.openjpa.jdbc.meta.strats.LobFieldStrategy class in the svn[1] or
> to the patch in the JIRA[2].
>
> There is a diferent behavior with the methods isCustomInsert, insert and
> customInsert, if you don't define isCustomInsert you only need to implement
> the insert method, also fot the update.
>
> If you have any questions don't hesitate to ask.
>
> Regards,
>
> - Ignacio
>
> [1]
>
> http://svn.apache.org/viewvc/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/meta/strats/LobFieldStrategy.java?revision=666914&view=markup
> [2]
> http://issues.apache.org/jira/secure/attachment/12365430/OPENJPA-130.patch
>
> On Fri, Aug 29, 2008 at 12:57 AM, Yuri <ydewit@gmail.com> wrote:
>
> >
> > I am wondering to what extent is is feasible to customize OpenJPA
> internals
> > by changing the way that Entities are
> > mapped/stored/retrieved/cached/queried.
> >
> > I am basically interested in keeping all the JPA semantics but want to
> > extend it to allow a modified schema to be generated that supports
> > versioning transparently.
> >
> > I looked at Hibernate hoping that it would be easy to get in,
> > extend/replace
> > a few classes and have fine grained control of every aspect of the ORM
> > persistence. However, I found out that it makes assumptions in the code
> > that
> > inserting an entity into the db will always translate into a insert
> > statement when in my case it may translate into an update and an insert.
> >
> > Any words of wisdom about that before I explore OpenJPA?
> >
> > thanks in advance,
> >
> > -- yuri
> > --
> > View this message in context:
> > http://n2.nabble.com/Customizing-OpenJPA-tp790926p790926.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message