Hi Kevin, This is good news. I took a quick peek at the code yesterday and so far I like what I see.
I can see that I will need to define my own annotation(s), extend entity metadata, override the implementation of insert/update/delete/select, change the generate db schema, possibly extend the caching implementation, and maybe later extend JPQL. thanks, -- yuri Kevin Sutter wrote: > > 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> 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. >> > >> > >> > > -- View this message in context: http://n2.nabble.com/Customizing-OpenJPA-tp790926p793580.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
