All of my exceptions are at runtime. :-)
On Mon, May 5, 2008 at 6:21 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> You don't have to declare the throw clause if it's a RuntimeException.
> The method signature doesn't have to change.
ethod 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:[EMAIL PROTE
ts 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:[EMAIL PROTECTED]
> Sent: M
ay, May 05, 2008 5:01 PM
To: user@cayenne.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 f
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
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 chec
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 <[EMAIL PROTECTED]> wrote:
> I guess my problem is that to me @depr
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 @deprecated.
I was planning to do both. Although we may decide to be gentle about
it and deprecate the method, but preserve the functional
I guess my problem is that to me @deprecate 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 @deprecating it but crippling it, then
I'd recommend remov
Maybe I'm simply misunderstanding what you meant by "actually ignoring
it in runtime".
To me, that sounded like you were going to change the behavior rather
than just mark the method as @deprecated.
On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
> @deprecated is the way we always do it. Th
@deprecated is the way we always do it. That's sort of implied.
Andrus
On May 5, 2008, at 8:26 PM, Mike Kienenberger wrote:
I don't have any opinion on the actual method involved, but when you
remove it, don't have it silently ignore the setting. Either get rid
of it completely (so compilati
I don't have any opinion on the actual method involved, but when you
remove it, don't have it silently ignore the setting. Either get rid
of it completely (so compilation/runtime breaks) or have it continue
to function (@deprecated with BIG warnings in the logs).
I'd hate to be a developer who m
On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote:
a set of queries with a large # of combinations of parameters, but
all searching the same underlying data set that rarely changes
On the other hand, even this example is better served by using query
cache. For a marginal increase in memor
13 matches
Mail list logo
