openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: [jira] Commented: (OPENJPA-442) JIRA-407 introduced backward compatibility problem in QueryImpl
Date Mon, 19 Nov 2007 15:35:27 GMT
> However, we need to define a set of deprecation rules in the openjpa
> documentation.

I'm not sure that the class in question is something that really
should make it into our docs -- we're talking about a pretty deeply
internal class. Recall that our docs are geared (should be geared?)
towards users of the products, not people who are looking to extend
it.

-Patrick

On Nov 19, 2007 7:11 AM, Teresa Kan <tckan1@gmail.com> wrote:
> Yes, I agreed with you that we need a deprecation rule to get rid of the old
> interfaces for API or SPI. I can add the @deprecated tag to the interface.
> However, we need to define a set of deprecation rules in the openjpa
> documentation.
>
> Teresa
>
>
>
> On 11/15/07, Patrick Linskey (JIRA) <jira@apache.org> wrote:
> >
> >
> >    [
>
> > https://issues.apache.org/jira/browse/OPENJPA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542921]
> >
> > Patrick Linskey commented on OPENJPA-442:
> > -----------------------------------------
> >
> > So I guess it depends what we consider to be a "public interface". To
> > date, we've defined that as just being things that are marked as @published.
> > Significantly increasing this footprint will make OpenJPA much more brittle
> > to refactorings.
> >
> > We might want to think about a relatively high-speed deprecation route for
> > things like this. This could help facilitate integration testing etc. while
> > still allowing things to change as we perform useful refactorings by
> > providing overlap in internal SPI compatibility.
> >
> > > JIRA-407 introduced backward compatibility problem in QueryImpl
> > > ---------------------------------------------------------------
> > >
> > >                 Key: OPENJPA-442
> > >                 URL: https://issues.apache.org/jira/browse/OPENJPA-442
> > >             Project: OpenJPA
> > >          Issue Type: Bug
> > >          Components: query
> > >    Affects Versions: 1.1.0
> > >            Reporter: Teresa Kan
> > >             Fix For: 1.1.0
> > >
> > >         Attachments: OPENJPA-442.patch
> > >
> > >
> > > In the openjpa-407 patch, it changed the constructor to pass an extra
> > parameter RuntimeExceptionTransaltor,
> > >    public QueryImpl(EntityManagerImpl em, RuntimeExceptionTranslator
> > ret,
> > >         org.apache.openjpa.kernel.Query query) {
> > >         _em = em;
> > >         _query = new DelegatingQuery(query, ret);
> > >     }
> > > However, it did not keep the orginial constructor so the extension  of
> > this QueryImpl from other vendor resulted in compiler error. We need to keep
> > the backward compatibilty issue in mind when we change the public interface.
> > > The solution will be  to add the original constructor back and route it
> > to the new constructor:
> > >    public QueryImpl(EntityManagerImpl em, RuntimeExceptionTranslator
> > ret,
> > >         org.apache.openjpa.kernel.Query query) {
> > >         _em = em;
> > >         if (ret == null)
> > >             ret = PersistenceExceptions.getRollbackTranslator(em);
> > >         _query = new DelegatingQuery(query, ret);
> > >     }
> > >     /**
> > >      * Constructor; supply factory and delegate.
> > >      */
> > >     public QueryImpl(EntityManagerImpl em,
> > org.apache.openjpa.kernel.Query query) {
> > >         this(em, null, query);
> > >     }
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>



-- 
Patrick Linskey
202 669 5907

Mime
View raw message