Re: Query.setRefreshingObjects(boolean)

From: Mike Kienenberger (mkienen..mail.com)
Date: Mon May 05 2008 - 18:21:25 EDT

  • Next message: Matthias Moeser: "Re: OracleSelectTranslator can not access OracleStatementWrapper"

    You don't have to declare the throw clause if it's a RuntimeException.
     The method signature doesn't have to change.

    On 5/5/08, Scott Anderson <sanderso..irvana.com> wrote:
    > > I don't see
    > > much benefit to providing a binary-compatible method API that does
    > > nothing.
    >
    > ...
    >
    > > Another possibility is to..eprecate the method and have it
    > > unconditionally throw a RuntimeException telling the developer to
    > > rewrite using query cache options.
    >
    >
    > Adding a Throws clause to the method would change its signature, thereby
    > breaking the binary compatibility of the method. It's a good idea, but
    > it won't solve that problem. :)
    >
    > Regards,
    >
    > Scott
    >
    >
    > -----Original Message-----
    > From: Mike Kienenberger [mailto:mkienen..mail.com]
    > Sent: Monday, May 05, 2008 5:01 PM
    > To: use..ayenne.apache.org
    > Subject: Re: Query.setRefreshingObjects(boolean)
    >
    > Just to reiterate, I see no problem with axing it entirely. I don't
    > think we have to nicely deprecate everything since we're now in 3.0
    > and it's marked unstable.
    >
    > However, we should make the need for change obvious. I don't see
    > much benefit to providing a binary-compatible method API that does
    > nothing. As an end-user, I want to see things either work as they
    > always worked, or be given a clear unavoidable indication that work is
    > required on my part to fix it.
    >
    > Another possibility is to..eprecate the method and have it
    > unconditionally throw a RuntimeException telling the developer to
    > rewrite using query cache options.
    >
    > On 5/5/08, Andrus Adamchik <andru..bjectstyle.org> wrote:
    > > Actually I was going to do the opposite, but since we've set the
    > backwards
    > > compatibility bar for ourselves pretty high in the past, I guess I am
    > > persuaded to go with deprecated-but-don't-cripple approach. I guess
    > that
    > > means also putting a deprecation note in the Modeler next to refresh
    > > checkbox.
    > >
    > > Andrus
    > >
    > >
    > > On May 5, 2008, at 11:36 PM, Michael Gentry wrote:
    > >
    > >
    > > > I'd like to second the opinion that deprecated still works (until
    > > > removed), but is discouraged from use. I believe that is what
    > Andrus
    > > > intends, though, given previous API changes.
    > > >
    > > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger
    > <mkienen..mail.com>
    > > wrote:
    > > >
    > > > > I guess my problem is that to me..eprecate means "it still works
    > like
    > > > > it used to, but it won't work in a future version and it's time
    > for
    > > > > you to change your code", but that's not what's going to happen
    > here.
    > > > >
    > > > > That's why if we're not really..eprecating it but crippling it,
    > then
    > > > > I'd recommend removing it. Giving end-users the false-hope that
    > > > > things are working as usual isn't very nice.
    > > > >
    > > > > You know the details of this particular situation better than I
    > do,
    > > > > though. If you don't think silently doing nothing will affect
    > > > > expected program behavior, go for it.
    > > > >
    > > > >
    > > > >
    > > > > On 5/5/08, Andrus Adamchik <andru..bjectstyle.org> wrote:
    > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > > >
    > > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote:
    > > > > >
    > > > > >
    > > > > >
    > > > > > > To me, that sounded like you were going to change the behavior
    > > rather
    > > > > > > than just mark the method as..eprecated.
    > > > > > >
    > > > > > >
    > > > > >
    > > > > > I was planning to do both. Although we may decide to be gentle
    > about
    > > it and
    > > > > > deprecate the method, but preserve the functionality (which will
    > put a
    > > bit
    > > > > > of extra maintenance burden on us).
    > > > > >
    > > > > > I am leaning towards the first option (deprecate and stop
    > invoking),
    > > > > > especially since the nature of the change results in enhanced
    > data
    > > > > > consistency, so there won't be any unpleasant surprises.
    > > > > >
    > > > > > Andrus
    > > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >
    > >
    > >
    >



    This archive was generated by hypermail 2.0.0 : Mon May 05 2008 - 18:22:03 EDT